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now, free simulation training and a 
no-obligation trial of SIMSCRIPT II.5 


before after 



learn how SIMSCRIPT II.5 simplifies your systems analysis 


S IMSCRIPT II.5 is the popular 
simulation language now widely 
used for systems analysis. 

Typical applications include: 
military, manufacturing, com¬ 
munications, logistics, and transpor¬ 
tation. 

Because of the complexity of 
these systems, you need careful 
analysis to evaluate alternatives and 
predict performance. 

Simulation with SIMSCRIPT II.5 
is more realistic, more easily under¬ 
stood, and more conclusive than 
other techniques, 
natural method of modelling 
SIMSCRIPT gives you an 
English-like language for describing 
a model of the system under study. 

When building a model in SIM¬ 
SCRIPT, you describe the simulated 
system as consisting of certain types 
of entities: flights and airports in a 
simulated air transport system; or 
jobs, processors, and I/O devices in 
a computer system. 

For each type of entity you give 
naipes to the attributes that 
characterize it. Each flight in an 
transport system for example, has a 
destination. The value of an at¬ 
tribute may be a number or a 
character string such as a message. 

You also name the sets an entity 
type may belong to, and the sets it 
may own. The simulation of an air 
transport system might include the 
stack of planes waiting at each 
airport. 


reduced cost 

SIMSCRIPT II.5® is a well 
established, standardized, and 
widely used language with proven 
software support. 

SIMSCRIPT II.5 reduces simula¬ 
tion programming time and cost 
severalfold compared to other 
simulation techniques, 
computers with SIMSCRIPT II.5 

1. IBM Personal Computer AT, 
XT, PC or compatible, with a fixed 
disk. 

2. Most mainframe computer 
types including IBM, CDC, Digital 
VAX, Univac, Gould, Prime, Data 
General and Honeywell. 

free trial and special offer 

The free trial contains everything 
you need to try SIMSCRIPT II.5 on 
your own computer. 

We send you PC or Mainframe 
SIMSCRIPT, installation instruc¬ 
tions, sample models, and a com¬ 
plete set of documentation. You can 
build your own model or modify 
one of ours. No cost or obligation. 

For a limited time we will also in¬ 
clude free training. Act now to 
avoid disappointment. 

Call Hal Duncan at (619) 


rush information on 
SIMSCRIPT II.5 special 
training offer and free trial 

free trial-Learn the reasons 
for the broad and growing pop¬ 
ularity of SIMSCRIPT II.5. Try 
Mainframe or PC XT-AT 
SIMSCRIPT II.5, user instruc¬ 
tions, training, documentation, 
and user support—no cost or 
obligation. 

special offer- Return the 
coupon today and you will be 
eligible for free training. 

□ Also send a free copy of 
the publication: the ten most 
frequent causes of simulation 
analysis failure. 
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or better yet, 
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Explore the Knowledge-based Society 
During the Professional Conference 


Really nine special conferences in one. Just to highlight one of the nine tracks covered at FJCC ’86— 


• Education 

• Software Systems 

• Artificial Intelligence 

• Supercomputing 

Algorithms 

• Modeling/Measurement 

• Computer Design 

• International Developments 

• Operating Systems/Data Bases/LAN’S 


FJCC ’86 Presents Algorithms 

Algorithms are at the core of computer science, and the FJCC ’86 
covers them in three dimensions - 

Paul Purdom’s track covers algorithms in the classic sense. Here 
are the latest advances in algorithms and data structures plus new 
J techniques for analyzing algorithms that will fuel future research in 
the area. 

's David Kincaid's track examines developments in numerical methods 
for treating large-scale scientific and operations research problems. 

An unusual treat is T.A. Marsland's track on algorithms for chess 
programs. These same algorithms might even be running right around 
the corner at the microchess tourney, or at the national computer 
chess competition. 

You can hear how it is done and then see it in action at the FJCC ’86. 
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PROFESSIONAL EDUCATION PROGRAMS 

The FJCC ’86 Professional Education 
Programs will provide computing pro¬ 
fessionals with the opportunity to 
enhance their knowledge and skills. To 
accomplish this, an extensive program 
of one and two day courses will be held 
on November 2 and 3. In addition to 
traditional lecture-style presentations, 
there will be hands-on workshops where 
attendees will use computer tools and 
techniques. 














Did you know that computers are now playing chess 
at the Grandmaster level? 

At FJCC ’86 you will see the World’s best experimental 
and commercial computers playing each other at a dual 
competition, November 1-6 in Dallas. 

The 6th World Microcomputer Chess Championship 
will take place during the day beginning Saturday, 
November 1 through Thursday, November 6, and the 
17th ACM North American Computer Chess Cham¬ 
pionship will be held in the evenings from Sunday, 
November 2 through Wednesday, November 5th. For 
more information and entry forms contact Professor 
Monroe Newborn, School of Computer Science, McGill 
University, 805 Sherbrooke Street West, Montreal, 
Quebec, Canada, H3A 2K6. 

JOIN US! — IT'S YOUR MOVE 


JOIN US AT FJCC ’86 

INFOMART—Dallas, Texas 

The Fall Joint Computer Conference ’86 
will be the forum for ACM’s and IEEE 
Computer Society’s Annual Conferences in 1986. 


Come see the 6th World Microcomputer Chess 
Championship and the 17th ACM North American 
Computer Chess Championship 


For further conference information, 
return the coupon or contact: 

• Conference 

Dr. Stanley Winkler 

FJCC’86 

1730 Massachusetts Ave., N.W. 
Washington, D.C. 20036-1903 

• Program 

Dr. Harold S. Stone 

IBM TJ. Watson Research Center 

P.O.Box 218 

Yorktown Heights, NY 10598 

• Professional Development 

Toni Shetler 

TRW Systems Division W1/4454 
7600 Colshire Drive 
McLean, VA 22102 

• Exhibits 

Tim Durkin or David McKeever 
INFOMART 

1950 Stemmons Freeway 
Dallas. TX 75207 
(214)746-3524 or (214)746-3542 


I- 

I Return to: FJCC ’86, 1730 Massachusetts Ave., N.W., Washington, D.C. 20036-1903 

■ □ YES. Pd like to attend FJCC ’86 and be where the action is on November 2-6, 1986 
I in Dallas. Please send me more information about the conference and professional 
| development programs. 

□ Please contact me regarding opportunities for exhibiting at FJCC ’86. 

I □ Please send me full information about the Chess Championships. 

I Name.. .Telephone_ 

I Affiliation ^ .*/ „■*. '. ‘ • 

I Street Address -v . . ^ ^ • 

I City/State/Country . ____ Zip 
























A High-Performance 
Memory Management 
Scheme 


Shreekant S. Thakkar, Oregon Graduate Center 
Alan E. Knowles, University of Manchester 


A new scheme 
replaces virtual- 
address-oriented 
page tables by real- 
address-oriented 
hardware page 
address registers. 
Parallel hashing 
hardware implements 
the page address 
registers. 


M odern computers usually imple¬ 
ment virtual memory as some 
form of paging, which was first 
introduced on Atlas. 1 The virtual address 
space available to the user program was 
much larger than the amount of expensive 
main memory provided, and the operating 
system organized transfers between the 
backing store and the memory whenever 
necessary. This ensured that those parts of 
the virtual address space currently in use 
were available in memory and relieved the 
user of organizing overlays. The mapping 
between virtual and real memory ad¬ 
dresses was performed by a set of associa- 
tively accessed page address registers, or 
PARs, maintained by the operating 
system. 

The memory was partitioned into 32 
pages, each 512 words, while the virtual 
address space was partitioned into 2048 
512-word blocks. Each PAR corre¬ 
sponded to a 512-word page frame in the 
main memory and held the virtual page, or 
block, number of the page residing in that 
page frame. These contents were main¬ 
tained by the operating system and up¬ 
dated each time a page frame was reallo¬ 
cated to a different virtual address block. 
In use, each virtual address was split in 
two; the top 11 bits were compared simul¬ 
taneously with all the PARs. If a page in 
memory had been set up to correspond to 
that virtual block, then a PAR would in¬ 
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dicate equivalence and the encode logic 
would yield a 5-bit number indicating the 
real page number. This when con¬ 
catenated with the least significant nine 
bits, or line, of the virtual address gave the 
full real address. Hence, the PARs per¬ 
formed the mapping between the virtual 
blocks and real pages. 

Figure 1 illustrates the process of ad¬ 
dress translation. The same address bits 
that specified the line, or displacement, 
within a virtual block specified the line 
within the real page. 

Failure to match a block with any PAR 
produced an interrupt (i.e., a. page fault), 
causing the operating system to take the 
necessary actions. These might include re¬ 
jection of a suitable page from memory; 
writing it back to the mass storage device, 
or drum; fetching the information cor¬ 
responding to the required virtual block 
from the drum into memory; updating the 
appropriate PAR contents; and returning 
to the interrupted program. 

On Atlas, the PARs were fully associa¬ 
tive, manufactured from discrete compo¬ 
nents configured as flip-flops for storage 
and equivalence gates for matching. 

Later generation machines used an in¬ 
dexed page table to perform address trans¬ 
lation (see Figure 2). The processor¬ 
generated address was divided into two 
fields: a virtual page number and a 
displacement within the page. The virtual 
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page number indexed a page table, from 
which the real page number was retrieved. 
The real page number was then con¬ 
catenated with the displacement to create 
the real address. To speed up translation, 
the page table was maintained in special 
high-speed registers. 

As the cost of memory fell and the avail¬ 
able main memory capacity increased, the 
use of the associatively accessed PAR 
scheme of Atlas, which had a register for 
every page in real store, became imprac¬ 
ticable. The size of the virtual address 
space had also increased, making it im¬ 
practical to hold a large page table in high¬ 
speed memory. Thus, the use of an address 
translation cache—fully associative cur¬ 
rent page registers, or CPRs, or set associ¬ 
ative translation look-aside buffers, or 
TLBs—backed up by full page tables in 
main memory, became the norm. This 
allowed extremely fast translation of that 
subset of virtual blocks currently in use. 
Denning 2 presents a comprehensive 
survey of the different techniques ex¬ 
ploited in the virtual memory systems, 
while Morris et al. 3 describe some recent 
techniques. 

Enchancements incorporated into later 
paged virtual memory schemes included a 
further division of the virtual address 
space into logically distinct segments, each 
comprising a number of blocks. In this 
way one segment might contain executable 
code; another might be a stack segment 
containing the variables declared in the 
user program; other segments might be 
used for input and output or contain ar¬ 
rays, etc. Protection against unauthorized 
access to segments prevents code being 
overwritten or private code being read 
rather than obeyed. As multiprogram¬ 
ming techniques developed, the concept 
grew of a virtual machine being made 
available for the exclusive use of each ac¬ 
tive process. This required a (possibly seg¬ 
mented) virtual address space for each 
process and led to the further expansion of 
the virtual address within the computer to 
include a process number field. 

Present schemes are characterized by 
several levels of page-table hierarchies 
held in main memory and backed by an 
address translation cache. Memory man¬ 
agement functions such as page replace¬ 
ment and manipulation of the virtual 
memory are done by the operating system. 
Schemes used on a new generation of 


Figure 1. Atlas page address registers. 


supermicroprocessors are based on those 
used on earlier mainframes. These 
schemes were based on performance 
studies carried out under different prevail¬ 
ing conditions than those present today. 
For example, the mainframes were used as 
time-sharing machines, while these micro¬ 
processors are most often found in a 
single-user environment. The page size 
used then was small primarily because the 
program size and the real memory size 
were smaller. However; this is not the case 
any longer; program size and real memory 
size are much larger. Very large address 
spaces, for example 64 terabytes (2 46 ) vir¬ 
tual address space and 4 Gigabyte (2 32 ) 
real address space on Intel’s iAPX386 are 
becoming a norm. 

Performance of the processors using 
virtual-address-based page tables, in terms 


of effective memory access time, depends 
on the performance of an address trans¬ 
lation cache. The performance of a cache 
degrades with context switches and con¬ 
tention, and is sensitive to its organization 
and the application programs. The need to 
support memory management functions 
more efficiently has become a necessity 
with large address spaces. Using virtual- 
address-based software page tables could 
result in poor real memory utilization and 
large overhead in maintenance. Further¬ 
more, several page faults could result dur¬ 
ing the address translation while trying to 
access the nested, paged page tables. 
Clearly, these schemes do not suit new- 
generation processors. 

A scheme that can support a paged vir¬ 
tual memory efficiently with minimum 
overhead has thus become a necessity. 
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Figure 3. Page table structure 
of MU5. 



Memory access is the bottleneck in Von 
Neumann architecture, so reducing the ef¬ 
fective memory access time can enhance a 
processor’s performance. 

We present a new way of organizing vir¬ 
tual memory management hardware using 
real-address-based hardware page address 
registers. The new scheme supports very 
large virtual and real address space, 
significantly reduces the need for software 
tables, and eliminates the need for an ad¬ 
dress translation cache. Hardware helps to 
manage the virtual memory. 

First we examine the memory manage¬ 
ment schemes implemented with software 
page tables and currently used in the ma¬ 
jority of systems. Second we describe the 
scheme treating real memory as a cache of 
virtual pages and its implementation in 
MU6-G 4 ’ 5 to overcome some of the in¬ 
efficiencies in existing systems. Finally, we 
propose a variation of this memory man¬ 
agement scheme using parallel hashing 
hardware. 


Address translation 
using software tables 

Virtual memory management schemes 
in most mainframes are implemented 
using some form of software tables and 
address translation cache for the most 
recently translated addresses. Newer 
32-bit microprocessor-based systems have 
adopted variations of the memory man¬ 


agement schemes found in these main¬ 
frames. Examples of systems using virtual- 
address-based page tables follow. 

Segmented paging in MU5. MU5, one 
of the earlier high-performance main¬ 
frames, supported a segmented, paged vir¬ 
tual address space for each of 16 processes. 
This scheme resembled the one used in the 
Multics operating system in that it sup¬ 
ported segmented paging, but differed 
from the pure paging schemes later used in 
the VAX/VMS and Berkeley Unix oper¬ 
ating systems. Location of a stored object, 
given its virtual address, was through the 
tables maintained by the operating system. 

Figure 3 illustrates the structure used by 
the MUSS 6 operating system in machines 
such as the MU5. One half of the virtual 
address space available to each process 
was common to all processes and was ac¬ 
cessed through a single common segment 
table, or CST. This allowed segments con¬ 
taining the operating system utilities, com¬ 
pilers, etc. to be shared by all processes. 
Entries in the CST pointed by means of a 
global segment table, or GST, to the page 
table for the segment concerned. Each ac¬ 
tive process also required, resident in main 
memory, its own local segment table, or 
LST, containing entries which, as in the 
CST, pointed by means of the GST to the 
page table for the segment concerned. The 
GST introduced an extra level of indirec¬ 
tion into the address translation process 
that allowed virtual addresses within 
several processes to share the same copy of 


the data. The page tables themselves may 
be paged; only those for currently active 
segments need be resident in main 
memory. 

The address translation was performed 
by using the appropriate fields in the vir¬ 
tual address to index the tables (see Figure 
3). While performing the translation, the 
access permission checking could detect a 
violation; appropriate action was then 
taken. The tables required to effect the 
translation, or the final page required, 
might not have currently resided in main 
memory. In that case, the operating sys¬ 
tem had to locate and transfer the table or 
the page from the backing store. 

Address translation using this scheme 
would be too slow if all translations had to 
go through these tables; hence this scheme 
was backed up by the use of fully associ¬ 
ative current page registers, or CPRs, 
which held the most recently translated 
virtual-real address tuples (see Figure 4). 
Unlike the PARs on Atlas, the CPRs 
covered less than the amount of real 
memory. Hence, the position of a CPR 
was not significant and a real address field 
was needed to hold the real page number. 
This field was held in a conventional ran¬ 
dom access memory. The operation of 
CPRs was still fully associative, as with 
PARs, but a miss could occur even when 
the desired page was in the main memory. 

As a result, CPRs were accessed first for 
all address translation. The virtual page 
number from the current virtual address 
was compared with all the CPRs simultan- 
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Figure 4. Ad¬ 
dress transla¬ 
tion using 
CPRs. 


eously. If a match occurred, the encoded 
match address was used to access the cor¬ 
responding real address field. The ac¬ 
cessed entry was then concatenated with 
the displacement from the virtual address 
to form the real address. When the CPRs 
gave a not-equivalence (that is, the search 
failed), the main tables were accessed. If 
the translation was successful, a suitable 
CPR was rewritten. If not, a page fault 
had occurred. This was handled by the 
operating system in the MU5, and is usual¬ 
ly handled by firmware and the operating 
system in the new-generation processors. 

In the MU5 the tables were structured so 
that table entries existed for each virtual 
page. All the entries for a particular seg¬ 
ment were in one indivisible page table oc¬ 
cupying a page of main memory while any 
page in that segment was in use. This struc¬ 
ture permitted access by simple indexing as 
described above. Each segment in the 
MU5 contained up to 256 pages, each IK 
byte. Thus, since each page table entry re¬ 
quired four bytes, a page table for a seg¬ 
ment occupied exactly one page. When the 
system was being used by a large number 
of people performing interactive tasks 
such as text editing, the time-slicing 
mechanism caused frequent process 
changing. The net result was that, for each 
segment being used by each person, only 
one page was resident together with 
various, relatively few, segment tables. 
Thus, a situation could arise in which 
nearly 50 percent of the main store was 
occupied by tables. 


Paging schemes. DEC’S VAX 11/780 is 
typical of systems employing a pure paging 
scheme to implement virtual memory. The 
virtual address divides the address space 
into system and user regions. The user 
space further divides into regions for code 
and data. Appropriate space and region 
are selected by the two most significant 
bits of the virtual address. Virtual address 
translation is performed by using the vir¬ 
tual page number, from the virtual ad¬ 
dress, to index the page tables held in main 
memory. A set of registers holds the base 
address and the length, or limit of the page 
table for each region. The real page num¬ 
ber from the indexed entry is concatenated 
with the displacement to form the real ad¬ 
dress. Since the current length of a page 
table is maintained, there is no need for the 
entire page table to be allocated in memory 
if it is not used. 

Translation lookaside buffers, or TLBs, 
with two-way set associative organization 
are used to hold the most recently trans¬ 
lated addresses. The TLBs mask the rela¬ 
tively long time taken to access page tables 
in main memory for address translation. 
The translation is performed by using the 
seven least significant bits of the virtual 
page number to index the TLBs. The in¬ 
dexed entry from both sets is compared 
with the remainder of the virtual page 
number from the virtual address. 

The TLBs also divide into system and 
user regions. The most significant bit of 
the virtual address is used to select the ap¬ 
propriate region. If the comparison results 


in a match, the real page number from the 
indexed entry is concatenated with the 
displacement to form the real address. If a 
miss occurs, the page tables must be ac¬ 
cessed to perform address translation and 
subsequently update the TLBs. The 
memory management functions such as 
page replacement are entirely handled by 
the operating system software. This 
scheme has the same disadvantages as the 
MU5 scheme. 

Other variations. Recently, two 
schemes have used the earlier technique of 
holding indexed page tables in high-speed 
memory, primarily to avoid the overhead 
associated with page tables held in main 
memory. 

Sun Microsystem’s Sun workstation 
uses segmented paging to implement its 
virtual memory system. The virtual ad¬ 
dress is made up of the virtual page num¬ 
ber with segment and block fields, and the 
displacement. A 4-bit context register 
allows 16 processes to be mapped concur¬ 
rently. Address translation for a process is 
performed by accessing its segment and 
page tables, which are held in high-speed 
memory. The segment number is used to 
index the segment table. The indexed entry 
is concatenated with the page number to 
access the page table. The real page num¬ 
ber from the page table is concatenated 
with the displacement to form the real ad¬ 
dress. A clever technique used here takes 
advantage of the characteristic of dynamic 
random access memory, or DRAM, used 
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Figure 5. MU6-G page ad¬ 
dress registers. 


Figure 6. Format for 
32-bit wide PAR. 
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to implement the workstation’s main 
memory. These DRAMs are accessed first 
by accessing a row with lower order bits of 
an address and then by accessing a column 
using the high order bits. Hence, the main 
memory is cycled using the displacement 
as the row address while the address trans¬ 
lation is performed. If the address trans¬ 
lation is successful, the main memory is 
then cycled using the real page number as 
the column address. This technique elimi¬ 
nates the need for an address translation 
cache. Trade-offs between the speed of 
translation tables and main memory, and 
table size and page size have made this 
scheme possible. 

AT&T’s Unix personal computer system 
uses paging to implement its virtual 
memory. The page table is held in high¬ 
speed memory, as in earlier mainframes. 
The size of the virtual memory supported 
is 4M bytes. The virtual address comprises 
a 10-bit virtual page number and 12-bit 
displacement within the page. Here the 
number of virtual pages is traded off 
against the page size to reduce the size of 
the page table. However, just as with other 


schemes the operating system entirely per¬ 
forms the memory management function 
in both machines. Such schemes may be 
attractive for a small processor where 
small virtual and real address spaces are 
used. 


Address translation 
using hardware PARs 

An alternative approach was adopted in 
the MU6-G to avoid the store usage ineffi¬ 
ciency already described for the MU5. The 
page table size was reduced to cover only 
those pages currently resident in main 
memory, the entries containing the virtual 
address currently mapped onto that par¬ 
ticular page. Instead of merely indexing 
the tables to perform address translation, 
the table entries had to be searched to find 
one whose content matched the virtual 
page or block number. If found, the 
matching entry number defined the main 
memory location of the page. Otherwise, 
the operating system had to deal with the 


page-fault condition. In that case the seg¬ 
ment tables yielded the location on the 
backing store of the required segment and 
hence the required page (since a segment 
on the backing store occupies contiguous 
locations). 

On the MU6-G, the virtual store was im¬ 
plemented using the same philosophy as 
the Atlas scheme, that is, there was a page 
address register for every page in the main 
store, hence full coverage of the store. 
Hardware PARs removed the need for 
page tables in the store since all the pages 
in the store are covered by the PARs. 
Thus, until a page fault occurred, no 
reference to the other tables was needed. 
However, the capacity of the main store 
had increased dramatically since Atlas, 
making it impracticable to provide fully 
associative PARs. The content-address¬ 
able memory used for implementing fully 
associative stores had not increased in 
capacity as had the conventional random 
access memory. 

The prototype MU6-G had 2M bytes of 
real storage with provision to expand to 
8M bytes. Each page was 2K bytes, hence 
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1024 PARs were required for the pro¬ 
totype, up to 4096 PARs when fully ex¬ 
panded. The PARs were arranged as 16 
groups of 256 PARs (see Figure 5) so that 
they could be searched in parallel. This 
search time was considered acceptable 
since the PARs were backed up by 32 
CPRs held in a fully associative store 
whose anticipated hit-rate was in excess of 
99 percent (based on the hit rate of MU5’s 
32-entry fully associative CPRs * 1 2 3 * * * 7 ). 

Using this scheme, the number of the 
PARs could be increased modularly when 
increasing the real store. Hence the cost of 
this scheme was kept down and the perfor¬ 
mance was unaffected. 

The idea of segments common to all 
processes was still possible, but the con¬ 
cept of shared segments between selected 
processes had to be abandoned because 
each PAR could hold only one virtual page 
number. At the time, it was felt that aban¬ 
doning sharing of private segments be¬ 
tween user processes would not have as 
great an impact on store utilization as 
would the sharing of system utilities such 
as compilers, editors, and libraries. 

Each PAR was 32 bits wide and had the 
format shown in Figure 6. The process, 
segment, and block number fields repre¬ 
sented a virtual page number. The access 
bits indicated the type of access permitted 
to that page. The used and the altered bit 
were used by the page rejection (replace¬ 
ment) algorithm. The lockout bit was used 
by the operating system to prevent access 
to certain pages (such as those being trans¬ 
ferred to/from the backing store). 

By performing the address translation 
entirely in hardware, the task of the 
operating system was made much simpler. 
The virtual memory management hard¬ 
ware also provided additional assistance to 
the operating system in managing the vir¬ 
tual store. 8 

In MUSS on the MU6-G, the page re¬ 
jection algorithm used was a variation of 
clock , which is a simple approximation of 
the global LRU replacement algorithm. 9 
Part of this algorithm was implemented in 
hardware. 

The MU6-G had 32 fully associative 
CPRs (similar to Figure 4) used to mask 
the relatively long search time of the 
PARs. They were totally transparent to the 
operating system and entirely controlled 
by the hardware. They behaved as an ad¬ 
dress translation cache and contained the 


most recently translated virtual-real ad¬ 
dress tuples. 

The CPRs were organized in two fields, 
an associative part and a real part. The 
associative part held the virtual page num¬ 
bers and the real part the corresponding 
real page numbers and the access bits. 

The translation from virtual page num¬ 
ber, or VPN, to real page number, or 
RPN, was performed by associating the 
current VPN with the associative parts of 
all the CPRs. If a match occurred, the 
match address was encoded to address the 
real part. The access bits stored in the CPR 
were compared with the attempted access. 
If the access check failed, an access vio¬ 
lation had occurred and a page-fault inter¬ 
rupt was generated. The real address was 
formed by concatenating the RPN with 
the word number (the displacement within 
the page) from the virtual address. The 
status bits in the appropriate PAR were 
updated after every store access. 

However, when a miss occurred in the 
CPRs, a PAR search was initiated and, if 
successful, a CPR was loaded with the 
found PAR. If the PAR search was unsuc¬ 
cessful, a page fault interrupt was gen¬ 
erated. Access checking was also per¬ 
formed in the PARs. If permission was 
violated, an access fault had occurred and 
a page-fault interrupt was generated. In 
all cases, whenever a page-fault interrupt 
was generated, the offending VPN was 
trapped in a register that could later be 
interrogated by the operating system. 

The PARs removed table overheads in 
main memory and cut the cost of content- 
addressable memory by using conven¬ 
tional memory that could be searched 
rapidly. The MU6-G’s memory manage¬ 
ment scheme had several advantages over 
schemes based on software page tables. 
The PARs could be sequentially searched 
(in parallel banks) and were backed by the 
fully associative CPRs, all hardware 
driven. The memory management soft¬ 
ware in the operating system was simpli¬ 
fied by hardware-assisted page replace¬ 
ment and context searches. 

Proposed address 
translation scheme 

The address translation on the MU6-G, 
performed using the associative CPRs and 
the PARs, provided a full coverage of 


The memory 
management 
software in the 
operating system 
was simplified by 
hardware-assisted 
page replacement 
and context 
searches. 


storage without any of the overheads 
associated with software page table 
schemes. Address translation was per¬ 
formed at a very high speed for the major¬ 
ity of store requests. However, the prob¬ 
lems with this scheme were: 

(1) For every request, access had to be 
made to both the CPRs and PARs. 

(2) For certain address sequences where 
a CPR miss occurred, sequential PAR 
searches had to be performed. This re¬ 
quired several microseconds. 

(3) Extra PARs had to be added every 
time storage capacity was increased. 

All of these problems have led to con¬ 
sideration of an alternative scheme based 
on the principle of total store coverage. 

Ideally, the new scheme should have only 

one level of address translation and should 
be able to support very large virtual and 

real address spaces. The ideal method as 
stated earlier would be to have fully 
associative PARs. However, the current 
state of content-addressable memory 
makes this method impractical. Hence, 
another alternative to fully associative 

PARs (besides the scheme already used to 
implement PARs in the MU6-G) is to use a 

hash table to emulate associative memory. 

Two address translation schemes (de¬ 
scribed below), also designed to support 
very large virtual and real address spaces, 
were based on real-address-based page 
descriptor tables. 

Hash tables have been used to imple¬ 
ment the address translation mechanism 
in the Monads II 10 and in IBM’s Sys¬ 
tem/38. 11 Similar schemes have been used 
in recently announced processors: the 
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Figure 7. Monads II address translation mechanism. 
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Figure 8. Address translation on IBM System/38. 


IBM PC-RT, HP Spectrum, and Xerox 
Dragon. 

In the Monads processor a single hash 
table, implemented in hardware, performs 
address translation (see Figure 7). The 
scheme used in the Monads processor 
eliminated the use of an address trans¬ 
lation cache, without suffering any signifi¬ 
cant degradation in performance. This 
scheme relied on the assumptions (1) that 
acceptable performance can be obtained if 
the hash table is sparsely occupied and (2) 
that hash addresses will be uniformly dis¬ 
tributed. 

On the Monads, the size of the hash ta¬ 
ble was four times the number of page 
frames in the real store. The expected 
number of probes (accesses to the table) to 
perform address translation was 1.125, 
which is acceptably low. (Note that for a 
fully associative table only one access is re¬ 
quired to perform address translation.) 

The IBM System/38 had a large virtual 
space (with 48-bit virtual addresses). To 
cope with this, a concept similar to Atlas 
and MU6-G address translation schemes 
was used, including an entry in its page 
frame directory, or PFD (also called an in¬ 
verted page table), for each page frame in 
the main store and a one-to-one cor¬ 
respondence with an entry in the PFD and 
a page frame in the main store. 

A hashing technique with overflow 
handling by chaining was used to perform 
address translation in the IBM System/38 
(see Figure 8). The virtual address was 
composed of a virtual page number, or 
VPN, and a byte number. The VPN was 
used to generate a hash address (or index) 
to access a hash index table, or HIT. An 
entry in this table held the page frame 
number, or PFN, used to access the page 
frame directory. 

An entry in the page frame directory 
held a virtual page number, a link field, 
and some control flags. The link field 
served as a pointer to the entry in the page 
frame directory, which was part of the 
overflow chain of the current entry. After 
an entry in the page frame directory was 
accessed, the current virtual page number 
was compared with the accessed virtual 
page number. If a match had occurred, 
then the page frame number was the real 
page number and was concatenated with 
the byte displacement from the current vir¬ 
tual address to form a real address. 


COMPUTER 










































































Figure 9. 

Organization of 
parallel hashing 
hardware. 


However, if the comparison failed and 
the accessed entry was the last one in its 
overflow chain, then a page fault was in¬ 
dicated. If there were more entries in the 
overflow chain, then the entry pointed to 
by the link field of the current entry was 
accessed and comparison performed. 

As in the Monads scheme, hash ad¬ 
dresses were assumed to be uniformly dis¬ 
tributed. The average number of page 
directory entries probed depended on the 
ratio of the hash index table to the size of 
the page frame directory. Hence, the size 
of the hash index table was selected to be 
twice the size of the page frame directory. 
The average number of accesses required 
to perform address translation was 1.25. 

However, both the hash index table and 
page frame directory were implemented in 
the main store and access to these tables 
took place at main memory speed. Ad¬ 
dress translation using this scheme would 
be too slow if all translations had to go 
through this hash table in main memory, 
so a 128-entry translation lookaside buffer 
was used. 

The schemes using a single hash table 
for address translation suffer from the fol¬ 
lowing drawbacks: 

(1) The size of the hash table had to be 
four times the total number of pages in the 
store in order to keep the number of 
probes needed to perform the address 
translation close to unity. 


(2) Chaining is used for handling colli¬ 
sions. 

(3) No hardware assistance is provided 
for virtual memory management func¬ 
tions such as page replacement and con¬ 
text searches for manipulation of virtual 
address space. 

To overcome the limitations of the 
MU6-G scheme and the schemes using a 
single hash table, we propose a new ad¬ 
dress translation scheme based on parallel 
hashing hardware. 12 This scheme, just as 
in Monads, eliminates the use of an ad¬ 
dress translation cache and provides a full 
coverage of the real store, as in MU6-G’s 
address translation mechanism. 

Parallel hashing hardware. The parallel 
hashing hardware consists of three major 
components: a hash address generator, or 
HAG; a hash table-, and a controller (see 
Figure 9). When presented with a search 
word, or item, HAG generates a hash ad¬ 
dress used in the interrogation of the hash 
table. 

The hash table is organized as J parallel 
banks of M words. Entries from each 
bank are accessed in parallel using the hash 
address. A comparator is associated with 
each bank, performing comparison be¬ 
tween a given key k and the accessed key 
ky, (15=y5 = 7,15 = t'5 = M). In the paral¬ 
lel hash table of ./banks, the first entry in a 
line can be thought of as the primary loca¬ 


tion for data when accessed by a hash ad¬ 
dress. The entries in the rest of the line can 
be considered secondary locations (J- 1 
entries). Hence the primary location and 
J- 1 secondary locations are accessed in 
parallel. 

Each entry in the hash table has an 
empty bit (Ey) associated with it, in¬ 
dicating whether the entry is empty or oc¬ 
cupied. Collisions are handled using an 
open addressing 13 mechanism. That is, 
when a clash occurs (all banks are oc¬ 
cupied and give no key match), a second 
access or probe is made to the hash table, 
using another hash address. This address is 
either computed using one of the probing 
techniques 13 or rehashed using a different 
hashing algorithm. Open addressing is 
faster than chaining because it can take 
advantage of parallelism during memory 
accesses. 

When accessing an item, the hash table 
is searched until an empty location is 
found, a match occurs, or all the entries 
have been examined. A conflict counter 
associated with each line of the hash table 
resolves the next empty location during an 
insert operation (adding a key) and the end 
of a search during a delete operation 
(removing a key). The counter is in¬ 
cremented for every probed entry for 
which there is no empty entry in any bank 
during an insert operation, and decre¬ 
mented for every failed probe entry during 
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Figure 10. Hash ad¬ 
dress generator. 


a delete operation. In this way, the search 
operation can resolve whether to proceed 
with the search for a given key. 

The manipulation of the conflict 
counters requires previous knowledge of 
the absence or presence of a matching key 
in the hash table. Hence a search must be 
done to ensure that a matching key is ab¬ 
sent (or present) before an insertion (or 
deletion) and subsequent manipulation of 
conflict counters can be performed. 
Therefore, conflict counters serve two 
purposes: 

(1) prevent erroneous termination of a 
hash probe sequence even if an empty en¬ 
try is encountered (If the counter is not 
zero, continue. There are other entries 
with the hash address elsewhere.); and 

(2) decrease the number of probes re¬ 
quired for an unsuccessful search. (If the 
counter is zero, then end of search.) 

The penalty for using the conflict 
counter is the extra amount of storage re¬ 
quired for the counter, M log 2 N bits, 
where N is the maximum number of active 
entries in the hash table. (For PAR ap¬ 
plications, N is the number of real page 
frames.) 

The load factor a for the parallel hash 
table is given by N/ ( MJ ). It is assumed 
that the hash table is always below a pre¬ 
specified maximum load factor a m (where 
a m is N m /(MJ)). 

Design parameters for hashed PARs. 

Goto presented the values for the number 


of probes required for unsuccessful 
search, or PU, and successful search, or 
PS, based on probability and simulation 
studies, for the worst case with different 
values of maximum load factor a m and J. 
Goto did not state what values of M and N 
he assumed. Knuth 14 assumed these values 
to be infinite for a similar study. Goto also 
did not mention the type of hashing func¬ 
tion and probing functions used in his 
studies. However, the study did show that 
the worst case for PU and PS is when dele¬ 
tions and insertions take place alternately, 
keeping the load factor very close to the 
permissible maximum a m in the statistical 
equilibrium. 

In an address translation mechanism, 
high efficiency in successful search is of 
utmost importance. A large value of PU 
may be tolerable if unsuccessful search 
does not occur often. For the MU6-G, the 
need to access the local store was greatly 
reduced by the presence of a high- 
performance instruction and data cache 15 
in the virtual memory management unit. 
However, the status bits in the PARs do 
have to be updated after every store re¬ 
quest. Hence, the average number of 
probes required to perform address trans¬ 
lation should be close to one. Using Goto’s 
figures, acceptable values of PS and PU 
for a hashed PAR table are between 1.27 
and 1.02 and between 1.65 and 1.13, 
respectively. This would suggest that the 
maximum load factor a m is 0.6 with 7= 8. 
These figures should be clearly confirmed 


by further simulation studies, since some 
assumptions about the values of Mand N 
have been made. 

Suppose that for the MU6- G, given that 
4K PARs (i.e., N m = 4K) are required to 
cover 8M bytes of real storage, the size of 
the required hash table would be less than 
7K. The hash table could be implemented 
with 8 banks using IK x 4 bits ECL RAM 
chips. (ECL 1 OK and 100K technology was 
used to implement the MU6-G processor.) 
This would make the size of the hash table 
8K, which improves both the value of the 
maximum load factor a m to 0.5, and the 
values for PS and PU. 

Choice of the hashing function. Im¬ 
plementation of a hashing function in 
hardware means that it must be able to 
generate a hash address rapidly. This 
limits the choice of hashing functions to 
the simple ones like hash-bit extraction, 
folding variations, or digit analysis. 13 
From experience in generating a hash ad¬ 
dress for a cache design based on a 
similar principle 16 and examining other 
schemes, 10 it seems likely that hash-bit 
extraction would be most suitable for this 
application. 

The initial hash address h a {k) can be 
generated using the virtual page number as 
the key. Taking the MU6-G virtual page 
number as an example, the three least 
significant bits of the segment number and 
the seven bits of the block number could 
form a 10-bit hash address. A simulation 
study would be required to confirm the 
choice for the hashing function. 

Choice of the probing function. When 
the first access to the hash table fails, a 
subsequent hash address must be deter¬ 
mined by a probing function. In choosing 
a probing function for implementation in 
hardware, a slower function than the one 
used for generating the primary hash ad¬ 
dress can be used, since the probe address 
can be generated in parallel with the access 
of the hash table using the current hash 
address. 

Linear probing techniques are usually 
easy to implement in hardware, but suffer 
from primary and secondary clustering. 13 
A variation of the linear probing tech¬ 
nique proposed by Luccio 17 can avoid 
both types of clustering, but it is expensive 
to implement in hardware and slow in per¬ 
formance because it requires multiplica- 
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tion. A random probing technique for this 
design requires the storage of about 1000 
pseudo-random numbers in a PROM. The 
difficulty here is finding a suitable se¬ 
quence. This technique does not suffer 
from primary clustering, but it does suffer 
from secondary clustering. Usually these 
techniques are very expensive to imple¬ 
ment in hardware and are slow in gener¬ 
ating a probe address. 

A quadratic probing technique pro¬ 
posed by Hopgood and Davenport 18 is 
useful for a table whose size is a power of 
two. It is employed here. This technique 
does not require expensive logic and 
generates the probe address very rapidly. 
It also ensures that the whole table is 
searched. This technique does not suffer 
from primary or secondary clustering. The 
search algorithm using this technique 
follows: 

(1) Compute initial hash address 
h—h 0 (k) and set the number of probes i 
to 1 where k is the key. 


(2) If any of the banks has its fith loca¬ 
tion empty or contains k, terminate the 
search. 

(3) Otherwise set h~[h + /] mod M, 
i—i + 1 and go to Step 2. 

The end of the probing sequence is 
reached when the tth and (/+ l)th probe 
addresses are the same. This condition in¬ 
dicates that the entire table has been 
searched. The 0'+l)th probe address is 
generated when probe address i is used to 
interrogate the hash table, hence no time is 
lost in generating probe addresses. 

Hopgood and Davenport give figures 
for the average length of search E(a), 
where a is the load factor. They used sim¬ 
ple linear and quadratic probing tech¬ 
niques, including theirs, on a single hash 
table of size 2K. These figures show that 
their quadratic probing technique has a 
superior performance to simple linear 
probing techniques and almost equal per¬ 
formance to other quadratic probing tech¬ 
niques. As with the other statistics, these 


figures need to be confirmed by a simula¬ 
tion study. 

The hash address generator for the PAR 
hash table (see Figure 10) incorporates 
generation of the initial hash address and 
subsequent probe addresses. 

Organization. We describe a design of 
an address translation mechanism for the 
MU6-G using a parallel hash table so that 
we can make a comparison between the 
MU6-G’s existing scheme and the alter¬ 
native scheme. The address translation 
hardware (see Figure 11) consists of a 
HAG (as described above), a parallel hash 
table, and a PAR information table, or 
PIT. 

The hash table should consist of eight 
parallel banks, each holding IK 27-bit 
entries with each entry having the format 
shown in Figure 12. 

The key field should be made up of the 
13 most significant bits of a VPN, that is, 8 
process bits and the 5 most significant seg- 
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1 Key 

Empty 

Lockout 

Real page number 1 


I Used 1 Altered 1 Access 1 VPN 1 

1 13 

1 

1 

12 


| 1 | 1 | 4 | 23 | 








Figure 12. Format for hash table entries. Figure 13. Format for PIT entries. 


ment bits. The empty bit would indicate 
whether the location holds a valid entry or 
is empty. The lockout bit, if set, would in¬ 
dicate that the page pointed to by the PAR 
is locked out because it is in transfer from 
or to the backing store and hence could 
not be accessed. The real page number, or 
RPN, is the number of the page in the 
store to which the VPN is mapped. 

A comparator associated with each 
bank performs a comparison between the 
accessed key and the 13 most significant 
bits of the current VPN. If the accessed 
location is empty, the comparison fails to 
indicate a match. 

The RPN is selected from the bank 
whose comparator indicates equivalence 
and is strobed into a counter called 
CPARNO used to access the PIT that 
holds 4K 29-bit entries, each having the 
format shown in Figure 13. 

Each entry in PIT has a one-to-one cor¬ 
respondence with a page in the local store, 
that is, location 0 points to page 0. 

The used and altered bits are status bits 
and would serve the same purpose as those 
in the MU6-G’s PARs. The used bit would 
be set when the page concerned is accessed 
by the processor. The altered bit would be 
set when the page is written to. The used 
bit would be examined in determining 
which page can be rejected (replaced) and 
the altered bit would be examined iri deter¬ 
mining whether the rejected page needed 
to be written back to the backing store. 
These bits would be updated when address 
translation is performed. 

The access bits, as in the MU6-G, would 
indicate the type of access permitted to 
that page. A comparator attached to PIT 
performs comparison between the at¬ 
tempted access and the permitted access. 

The main reason for PIT is to imple¬ 
ment the clock page rejection scheme 
more efficiently. By having used and 
altered bits in a separate table, it is possible 
to maintain PARs in a circular order for 
the clock algorithm. The reason for access 
bits being in the PIT instead of the hash 
table is to save storage and reduce the 


number of comparators required. The 
penalty for this is that address translation 
will be slower because of having to per¬ 
form access checking after looking up the 
stored access bits in PIT. 

The page rejection algorithm will give 
the RPN of the page to be replaced and the 
associated VPN. The VPN will then be 
used to access the hash table to eliminate 
the corresponding entry from the hash 
table. 

Operations on the PAR hash table. 

Address translation. Address trans¬ 
lation takes the following steps: 

(1) [Initialize] Set /-l, key A:-VPN. 

(2) [Hash address generation] Set 
h-hj(lc) and generate probe address 
/! i + i(k)-[A, (/t) + ;] Mod M, /-/ + 1. 

(3) [Parallel access to PAR hash table] 

(4) [Check for a match] If P[h,j] = k 

for some/ = 1.8; GOTO Step 5. The 

RPN is automatically available. 

Else if C[h] > 0, set h i (k)'-h i+I (k)\ 
GOTO Step 2. 

Otherwise, terminate the search and in¬ 
dicate a page fault. 

(5) [Access PIT using the RPN] Per¬ 
form comparison between the attempted 
access and the permitted access. 

If access is allowed, update the used bit 
(and the altered bit for write requests) and 
terminate the search, else terminate the 
search and indicate an access fault. 

Loading PAR operation. The following 
steps are taken when a PAR needs to be 
loaded: 

Steps 1 through 3 are the same as those 
for address translation. 

(4) [Check for emptiness] If P[hJ\ is 

empty for some j = 1.8, set P[hJ] —k, 

RPN and PIT[RPN]— access and status 
bits, VPN. Terminate search. 

Otherwise, set C[h] — C[h] - 1 and set 
hj(k) - h i+I (k). GOTO Step 2. 


Reject PAR operation. The following 
steps are taken when a PAR needs to be 
deleted: 

Steps 1 through 3 are the same as those 
for address translation. 

(4) [Check for match] If P[hJ ] = k for 
somey =1,..., 8, then set P[h,j\ empty. 
Reset status bits in the PIT and terminate 
the search. 

Otherwise, set C[/i]—C[h] - 1, and 
hi(k) -h i+1 (k). GOTO Step 2. 

Free PAR search. The following steps 
are taken when a free PAR (one with its 
used bit not set) needs to be located. This 
action involves a cyclic scan of PIT and ex¬ 
amination of the used bit of all the PARs 
(i.e., the clock algorithm). 

(1) [Initialize] Set CPARNO -0. 

(2) [Access PIT] Read out PIT 
[CPARNO], 

(3) [Examine used bit] If used bit set, 
then reset it. CPARNO-CPARNO + 1, 
GOTO Step 2. 

Else return value of CPARNO and VPN, 
or alternatively store it in a control register 
and terminate the search. 

Notice this search has nothing to do 
with the PAR hash table. The information 
required for the page rejection algorithm is 
separated from the hash table. In this way 
a different page rejection strategy could be 
used rather than the one used on the 
MU6-G. A VLSI implementation of the 
global clock algorithm proposed by 
Breidegard et al. 19 would be ideal for this 
application. 

Expected performance. The perfor¬ 
mance of the PAR hash table can be 
classified into (1) an address translation 
function and (2) other functions involved 
in maintaining the virtual store system. 

The address translation function can be 
performed in a time comparable to that of 
the MU6-G address translation cache. 
Hence, the virtual address translation for 
all the pages in the real memory is per¬ 
formed at cache speed. 
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The other functions, such as page re¬ 
placement and context searches, are done 
infrequently, hence the time they take does 
not affect the overall performance. 

Comparison with the 
MU6-G's PARS 

The performance of the address trans¬ 
lation function using the PAR hash table is 
slower than that of the CPRs on the 
MU6-G, primarily due to the access bits 
being stored in PIT instead of in the hash 
table. Hence the access comparison is not 
performed until PIT has been accessed. 
The slower performance can be tolerated 
if the address translation function is not on 
the critical path of generating the data- 
available strobe, as in the MU6-G. Note 
that if access permission bits were stored in 
the PAR hash table, then the address 
translation time is comparable to the 
CPRs on the MU6-G. 

The proposed scheme has several ad¬ 
vantages over the MU6-G address trans¬ 
lation design. There is no need for an ad¬ 
dress translation cache (CPRs/TLBs), 
since this scheme performs address trans¬ 
lation at cache speed for all the PARs. A 
single address translation table is easier to 
maintain than a hierarchy, an address 
translation cache (CPRs), and PARs. Less 
logic is required to implement this design 
(two boards as compared to the five 
boards on the MU6-G required to cover 
8M bytes). Sharing between user (private) 
segments is possible with the hashed 
PARs. 20 

All functions that can be performed on 
the MU6-G (CPRs/PARs) virtual memory 
management hardware can also be per¬ 
formed on the proposed PAR hash table. 


W e conducted this study to pro¬ 
vide a virtual memory manage¬ 
ment scheme for a large, multi¬ 
user, high-performance system that could 
overcome the limitations we observed on 
current systems and could support very 
large address spaces efficiently. 

We proposed an alternative approach to 
virtual-address-based page table schemes 
based on real-address-based page address 
registers. This scheme treats real memory 
as a cache of virtual pages and uses 
psuedo-associative mapping to perform 
address translation. 


The hashed PARs have a 100 percent 
hit-rate when compared with designs using 
an address translation cache, where the 
hit-rate varies between 85 percent and 99 
percent depending on the cache size and 
the application programs. The introduc¬ 
tion of the cache into the address trans¬ 
lation hierarchy brings its own set of prob¬ 
lems, namely cache misses due to context 
switches and contention. These come on 
top of the problems resulting from 
thrashing in main memory due to conten¬ 
tion and its allocation strategies. Thus, by 
eliminating the cache we have gotten rid of 
these problems and can concentrate on 
solving the real contention problem in 
main memory. The effective memory ac¬ 
cess time is also faster using hashed PARs 
for address translation, which increases 
processor performance. 

Thus, the parallel hash table offers an 
efficient implementation of paged virtual 
memory systems. Of additional benefit, 
the parallel hash table scheme can easily be 
extended to cover larger real address space 
than in the MU6-G without any significant 
degradation in performance. The PAR 
hash table can be modularly constructed 
so that its size increases only with the addi¬ 
tion of real memory. 

The scheme we describe may not be a 
suitable and cost-effective solution for dif¬ 
ferent types of processors, however. For 
example, performing address translation 
on-chip with VLSI microprocessors pro¬ 
vides a faster instruction cycle time than 
going off-chip for translation. Our scheme 
is too large to be integrated on-chip with a 
processor. Nonetheless, a variation can 
replace software page tables in these sys¬ 
tems. The PAR hash table can be imple¬ 
mented in a slower memory technology 
backed up with an on-chip address trans¬ 
lation cache. This variation provides a 
high-speed address translation for the 
most recently translated addresses and a 
fast search in the event of a cache miss. 
This alternative provides a better solution 
in handling very large address spaces than 
do existing implementations. 

The scheme as described also does not 
suit shared-memory multiprocessor sys¬ 
tems because replacing all the distributed 
memory management units, or MMUs, 
with a central MMU may create conten¬ 
tion. A similar solution to the one de¬ 
scribed for microprocessor systems can 
replace the virtual-address-based page 


tables with the hash table. This is a better 
solution for the shared memory mul¬ 
tiprocessor system since there may be 
more demands to search page tables 
because of the misses in the distributed ad¬ 
dress translation caches. These requests 
can be serviced rapidly with hashed PARs. 

Recent adoption of virtual memory 
management schemes based on similar 
principles by IBM and Hewlett-Packard 
for their new generation processors add 
support to our claims. We will gladly sup¬ 
ply further references for those readers in¬ 
terested in learning more about the 
subject. □ 
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Interconnections for 
rriulticomputers can 
be evaluated using 
such parameters as 
distance between 
nodes, number of 
communication links, 
degree of fault 
tolerance, and 
machine expansion 
capability. 


A s ever more powerful computers 
were developed, so did the 
demands made upon them (which 
is, of course, just an instance of Parkin¬ 
son’s law in action). However, there is a 
limit to the maximum speed obtainable 
from a computer based on a single pro¬ 
cessor. The closer we approach this limit, 
the more rapidly does the cost of such a 
computer rise. An alternative and radical¬ 
ly different solution is to move from this 
uniprocessor architecture to a newer ar¬ 
chitecture employing the time-tested 
device of parallelism, i.e., using a number 
of cooperating processors. The concept 
underlying parallel architectures is not 
new. Nature is full of instances where 
seemingly powerless creatures, such as 
ants and bees, achieve incredible feats by 
collective endeavor. All modern technol¬ 
ogy is the result of joint human effort. In 
fact, this approach has another point in its 
favor: because of advances made in VLSI 
technology, it has become possible to 
fabricate cheaply many processors on a 
single chip. Undoubtedly, there are many 
problems to be overcome, some of which 
seem almost insurmountable. We will 
discuss here some of the most fundamen¬ 
tal of these, and show the various ways in 
which these are being overcome. 
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A crucial decision that must be made in 
the design of such Multi-Computer Sys¬ 
tems, or MCS, is the level of parallelism, 
or, in other words, the size of the subtasks 
that the original task is split into. Different 
design philosophies have favored different 
sizes. 1 Each has its own strengths and 
weaknesses. At one end of the spectrum is 
the Data Flow Machine, or DFM, where 
each subtask is a single operation. The 
DFM has a problem in the amount of the 
communication overhead involved as each 
processor sends or receives data from 
another. On the other hand, using large 
subtasks, while reducing this burden, in¬ 
volves another (nontrivial) problem of 
properly partitioning the given algorithm 
into reasonably sized chunks, and then 
mapping these resulting subtasks on the 
available architecture in the most efficient 
manner. 

There have been many approaches to 
these new architectures that employ paral¬ 
lelism. In one of the simpler implementa¬ 
tions, numerous relatively simple proces¬ 
sors work on different sets of the data, 
performing the same set of instructions on 
each set. These processors will need to in¬ 
teract often in order to synchronize them¬ 
selves. Alternatively, we can have proces¬ 
sors working independently, interacting 
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only briefly and not very often. These pro¬ 
cessors can be geographically distant from 
one another. 

The approach we discuss here takes a 
middle road. This architecture consists of 
medium-power processors (such as those 
used in single-board computers), which 
are physically close together so that they 
may communicate easily, via dedicated 
links or communication paths, but which 
at the same time work relatively in¬ 
dependently of one another. 

Flynn 2 categorized the various classes 
of computers based on the way they 
operate and handle data. These categories 
are: SISD (Single Instruction Stream, 
Single Data Stream), SIMD (Single In¬ 
struction Stream, Multiple Data Stream), 
MISD (Multiple Instruction Stream, 
Single Data Stream), and MIMD (Multi¬ 
ple Instruction Stream, Multiple Data 
Stream). The classification is fairly logical 
and self-explanatory. In this article we are 
concerned with MIMD schemes, where 
different processors work on different or 
multiple data schemes, with each possibly 
executing different instructions. It would 
be extremely useful to have a reasonable 
methodology to evaluate the performance 
of various MIMD schemes, and thereby 
provide a possible design tool for use in 
such systems. Thus far, new architecture 
designs have been done mainly on an ad 
hoc basis. There is a need to replace such 
intuitive techniques with some systematic 
methodology. Although the MCS can 
conceptually provide a linear speedup over 
a uniprocessor system, practical systems 
fall far short of this because of problems 
with mismatch between the algorithm and 
architecture, overheads associated with 
data management and communications, 
etc. 3 

What can be done to optimize the per¬ 
formance of an MCS? From a common- 
sense point of view, three factors that 
could have a bearing on performance 
come to mind: (1) the interconnection 
scheme that ties all the processors togeth¬ 
er, (2) the scheduling and mapping of the 
algorithm on the architecture, and (3) the 
mechanism for detecting parallelism and 
partitioning the algorithm into modules, 
or subtasks, which, when run on an MCS, 
will achieve a computational speedup. The 
last of these issues is quite involved, and 
space will not permit a summary that 
would do it justice. 


Interconnection 
scheme issues 

When several processors are required to 
work cooperatively on a single task, one 
expects frequent exchange of data among 
the several subtasks that comprise the 
main task. The amount of data, the fre¬ 
quency with which they are transmitted, 
the speed of their transmission, and the 
route that they take are all significant in af¬ 
fecting this intercommunication. The first 
two factors depend on the algorithm itself 
and how well it has been partitioned. The 
speed of transmission is a function of the 
hardware used and is not the point of the 
discussion here. In this section, we con¬ 
cern ourselves with the last factor. 

Ideally, if one processor wants to com¬ 
municate with another, then it should do 
so over a channel that directly connects the 
two. A channel between every pair of pro¬ 
cessors would yield a system that is most 
versatile. Given a sufficient number of 
processors, there would be little or no 
problems with scheduling. Such a system 
is undoubtedly the most desirable. It 
would also be prohibitively expensive. A 
channel between every pair of processors 
would require 0(n 2 ) channels for n pro¬ 
cessors. For any significant n the total cost 
of these channels would swamp all other 
costs. We must, therefore, trade cost for 
speed and versatility. The compromise 
that is made involves routing data from 
one processor to another via intermediate 
processors, in cases where there is no direct 
link between the two processors. This has 
several repercussions. First, there is now 
an extra delay added in data transmission 
because of possible intermediate stages. 
Second, and perhaps more important, is 
the added capability that must be built into 
each processor that would allow it to per¬ 
form this routing intelligently. The pro¬ 
cessor must know whether a block of data 
it has received is for itself or is en route to 
another processor, in which case it must 
forward this block to the appropriate pro¬ 
cessor, which could be the destination pro¬ 
cessor or another intermediate processor. 
And conversely, when a processor wishes 
to acquire data from another, it must 
know how and when to access this data. In 
other words, the processors must be aware 
of some routing and synchronization 
rules, and these should be, preferably, 


both simple and efficient. The intercon¬ 
nection scheme must take into account all 
these factors. 

There have been many approaches that 
try to address this problem, viz., given 
these n processors, how to connect them in 
the most cost-effective manner. 

Broadly speaking, a viable interconnec¬ 
tion strategy (or topology ) must have a 
small number of channels, and relatively 
easy routing rules. There are also such 
other considerations as fault tolerance: 
how to reroute data and recover gracefully 
in case a processor fails. Each of the 
schemes has been proposed with a certain 
class of applications in mind. Therefore, it 
would not be possible to directly compare 
these schemes as there is, in general, no 
“best” scheme. Instead, what we have is a 
number of schemes, each of which has its 
particular area of usefulness. With the 
range of possible applications in mind, the 
designer must choose the most cost-effec¬ 
tive one for his purposes. Any evaluation 
of the performance of these schemes must 
be, to a certain extent, qualitative. How¬ 
ever, once a few candidate networks have 
been tentatively selected, detailed (and ex¬ 
pensive) evaluation including simulation 
can be carried out and the “best” one 
selected for the proposed application. 

It is instructive to examine, at least quali¬ 
tatively, some of the important charac¬ 
teristics of these interconnection schemes. 
We will first describe and define these 
characteristics and then evaluate various 
interconnection schemes vis-a-vis these 
characteristics. In what follows a distinc¬ 
tion is made between two classes of 
interconnection schemes. L/«£-oriented 
structures or schemes comprise those in¬ 
terconnection schemes in which there is a 
dedicated link or channel available for 
data transfer between two computers that 
are to be connected, flus-oriented struc¬ 
tures consist of multiple buses. Each bus is 
shared by a group of computers; commu¬ 
nication takes place in a series of hops, 
from computer to computer, via these 
buses. 

Network characteristics. We now look 
at some of the considerations in the evalu¬ 
ation of interconnection networks. In all 
these networks, it should be emphasized 
that improving one parameter might 
adversely affect some other parameters: 
what is sought is an optimization of the 
network. 
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Average distance. One of the more im¬ 
portant evaluative measures of an inter¬ 
connection network is the average dis¬ 
tance. This is the distance messages must 
travel, on an average, in the network. It is 
advantageous to make this as short as 
possible. The average distance (in terms of 
the number of links) is defined as: 4 

E dN d 

AvgDist = — 1 - 

N -1 

where N d is the number of computers at a 
distance d links away, r is the diameter 
(maximum of the minimum distance be¬ 
tween any two pairs of nodes), and TVis the 
total number of computers. 

For regular networks, i.e., those in which 
each computer is connected to the same 
number of other computers, the AvgDist 
is a constant. For irregular networks, the 
formula will yield different results, de¬ 
pending on the node from which d is mea¬ 
sured. A network that has a low average 
distance may require an unreasonable 
number of communication ports for each 
computer. In order to distinguish these 
cases, a normalized average distance is 
defined 4 for link-based structures: 

NormAvgDist (link) = 

AvgDist x Ports/comp (2) 
where Ports/comp is the number of com¬ 
munication ports required of each com¬ 
puter. 

In the case of bus structures, the dis¬ 
tance d is the number of buses a message 
has to cross on the way to its destination. 
Also, the number of computers tied to a 
bus is of importance as several computers 
on a single bus may create bottlenecks due 
to bus contentions. To account for this, 
we define the normalized average distance 
for bus structures as the average distance 
weighted by the number of computers that 
may have access to a single bus. 

NormAvgDist (bus) = 

AvgDist x Ports/bus (3) 

Communication links. The total num¬ 
ber of communication links in a network 
of given size is another useful measure. 
Clearly, among two networks, the one that 
has fewer connecting links is the more 
desirable, assuming (naively) all else is 
equal. 


Routing algorithm. When a message is 
to be routed from one computer to 
another, the route it must take is obtained 
from the routing algorithm. It is desirable 
that the routing algorithm be simple and 
not require a complete knowledge of the 
entire network. In particular, it would be 
convenient if, by merely having the desti¬ 
nation address, it is possible to obtain the 
exact—and preferably the shortest—se¬ 
quence of computers the message must 
traverse. 

Fault tolerance. If one of the computers 
along this route were to be faulty, then a 
breakdown in communication would re¬ 
sult, and this could make any further com¬ 
putation pointless. To preclude such a 
possibility, networks must be fault toler¬ 
ant. Fault-tolerant networks have at least 
one redundant path between any two com¬ 
puters; and these redundant paths are used 
in the case of a fault in a connecting chan¬ 
nel. Another fault that is potentially more 
dangerous is the failure of a computer. 
Should such a fault arise, it is desirable 
that the system bypasses this faulty com¬ 
puter in all future computations and re¬ 
main functional although possibly im¬ 
paired. This “graceful degradation” 
feature is desirable in certain critical areas, 
such as space and military applications. 

Expansion capability. Any large system 
must be capable of expansion in such a 
way that it causes a minimum of disrup¬ 
tion of the existing setup. Clearly, a net¬ 
work that requires a complete rebuilding, 
with fresh demands on the number of 
communication ports of individual com¬ 
puters, every time extra computers are 
added is less preferable to one that can be 
extended in a natural way, without major 
upheaval of the entire system. 


Link-oriented structures 

In this section we analyze some link- 
oriented structures. The issues mentioned 
in the previous section are dealt with in 
seriatim. 

The ring network. The ring structure is 
one of the simplest networks. The routing 
is simple and the structure has been well 
analyzed, mainly because, along with the 
star and tree networks, it is among the 


The routing algorithm 
of link-oriented 
structures is relatively 
straightforward, 
because of the 
simplicity of the 
network. 


most popular of the topologies used in 
Local Area Networks, or LANs. The to¬ 
pology has also been used in a Dataflow 
machine architecture. 5 ’ 6 It consists of a 
number of computers connected in the 
form of a ring, i.e., each connected to its 
two neighbors. Although most LAN to¬ 
pologies use a unidirectional ring (i.e., one 
in which data flows in one direction only 
around the ring), because of its obvious 
problem of poor fault tolerance, we will 
assume a bidirectional ring. 

Average distance. The average distance 
is easily found to be {N+ 1)/4, for a ring of 
^computers, where Nis odd. The case for 
N even is also easy to deal with, but the 
relations are not so neat. The normalized 
average distance is, of course, ( N+ 1)/2, 
as there are two ports on each computer. 
This linear relationship means that the 
distance may become unacceptably large 
for large N. 

Communication links. The total num¬ 
ber of communication links is N. 

Routing algorithm. The routing algo¬ 
rithm is relatively straightforward, be¬ 
cause of the simplicity of the network. It is 
simplest for unidirectional rings and only 
slightly more involved for bidirectional 
rings. 

Fault tolerance. The fault tolerance of 
the ring structure is questionable. If any 
node in a unidirectional ring fails, it may 
render the entire system nonfunctional. In 
a bidirectional ring the failure of two 
nodes will cause the same result. In order 
to alleviate this problem, several variants 
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Figure 2. A 

4x3x2 alpha 
network. 


have been considered by different re¬ 
searchers. 

Expansion capability. The ring network 
is obviously one of the simplest to expand. 

The cube connected cycles network. 

This network, proposed by Preparata, 7 


connects 2 k computers (k is an integer) in 
such a way that groups of 2 r (r is the 
smallest integer such that r+2 r >k) are 
interconnected so as to form a ( k-r )- 
dimension cube. Each computer has a 
Ar-bit address that is expressed as a pair 
(l,p) of integers, / having (k-r) bits, and p 
having /-bits. There are three ports, called 


F, B, and L (for Forward, Backward, and 
Lateral) provided on each computer, and 
the interconnection rule is: 

F (l,p) is connected to B(/, (p+ l)mod2''); 
B(/,p) is connected to F (l,(p- l)mod20; 
L (l,p) is connected to L(/+ e p ); 
where e = 1 - 2 x (p th bit of /). An exam¬ 
ple of such a structure for k = 5 is shown 
in Figure 1. 

Average distance. The average distance 
for the CCC is obtained as the product of 
the average distance of the subgroup of 2 r 
processors (which form a ring) and the 
main ( k - r) cube network. The number of 
ports in each computer is three, so the nor¬ 
malized distance is simply the average 
distance times three. 

Communication links. The total num¬ 
ber of communication links is at most 
(3/2 )N, where N is the total number of 
nodes in the network. 7 

Routing algorithm and fault tolerance. 
Wittie 8 gives a simple algorithm to route 
messages between computers. Even when 
a node is faulty, an alternative path may be 
found with ease. 

Expansion capability. Because of the 
cube structure employed, expansion is not 
easy. Not only must the expansion be in 
powers of two, but the system must be 
completely restructured. 

The alpha network. This is a generalized 
hypercube structure. 4 Unlike the hyper¬ 
cube, which needs the number of nodes to 
be of the form N= W D , the alpha net¬ 
work is valid for all nonprime values of N. 
The alpha network is constructed in the 
following manner: Let m ] ,m 2 ,.--,m D be 
chosen such that m, is integer and 

n m t= N 

Then each node can be expressed in a 
mixed radix form as a D-tuple (x D x D _ \ , 
...,JCi), which forms the address of the 
node. Connections are made from each 
node to every node whose address differs 
by 1 in any one coordinate. An example of 
an alpha network is shown in Figure 2. 

Average distance. The average distance 
in a network is given by 

D(W-\)W N ~ l 

AvgDist(alpha) =-(4) 

N-\ 
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The number of ports on each processor 
is given by 

Ports (alpha) = D(W- 1) (5) 

Communication links. The total num¬ 
ber of links is 

Links (alpha) = NX Ports/2 (6) 
Routing algorithm and fault tolerance. 
A simple routing algorithm is given in 


reference 4. Because of the several redun¬ 
dant paths that exist, this network is highly 
fault tolerant. 

Expansion capability. Since this net¬ 
work is a generalized cube network, ex¬ 
pansion is not easy as the number of ports 
is dependent on network size. Unlike cube 
networks, however, any nonprime value 
of Af can be accommodated. 


The hypertree network. The hypertree 9 
is basically a binary tree network, which by 
the judicious addition of extra edges con¬ 
necting sibling nodes, has been made to 
have a smaller average distance, and a 
measure of fault tolerance. These new 
edges are chosen to be n-cube connections; 
i.e., they link nodes that have (binary) ad¬ 
dresses that differ in only one bit. Each 
processor has four ports—one from the 
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parent, two to the children, and one to the 
sibling. 

As mentioned above, the linking of 
nodes is done with a view to decrease the 
distance between them. For example, in 
Figure 3(a), which shows an instantiation 
of a 15-node hypertree, the distance be¬ 
tween nodes 8 and 15 is six (ignoring sib¬ 
ling links for the moment). So the sibling 
links are chosen to reduce this distance. 
Figure 3(b) is a table given by Goodman 
and Sequin 9 showing these distances. An 
entry in the i th row and j ,h column of the 
table gives the distance between those sib¬ 
lings in the (/+ \) th row whose addresses 
differ in the j th bit position. A circled en¬ 
try represents the maximum for that row. 
Entries just below a circled entry are not 
considered because they are effectually 
reduced to three by the sibling links in the 
previous level. Entries two rows below a 
circled entry are reduced to five, and so 
on. With this table, the sibling links may 
be chosen in a fairly straightforward man¬ 
ner. For every level i, links are given by the 
value of the circled entry of the table. 

Average distance. The average distance 
of the hypertree is tedious to calculate 
using equation (1). The authors of 


reference 9 arrive at a formula using a dif¬ 
ferent approach and this yields a more 
conservative value. Their formula was 
used here. It should be noted that this net¬ 
work is not regular so equation (1) will give 
different results, depending on the origin 
node. 

Communication links. The total num¬ 
ber of communication links can be shown 
to be 

N+ 2(2 P°82^ v 1 - 1 -1) 

Routing algorithm and fault tolerance. 
The routing algorithm is given in reference 
9. Under fault conditions, the algorithmic 
procedure becomes rather more complex. 

Expansion capability. In common with 
tree structures, the network is easily exten¬ 
sible, and expansion requires a minimum 
disruption of the rest of the system. 

The multitree structure. The multitree 
structure 10 is another tree type structure 
that uses connections to sibling nodes to 
reduce the distance between them. An 
MTS ( m:t ) consists of m identical Compo¬ 
nent Trees, or CTs, each of t levels, which 
have their roots and their leaves circularly 


connected. A CT of an MTS graph of 
degree d is a rooted undirected tree, where 
each nonleaf node has (d- 1) children, ex¬ 
cept the root that has ( d - 2) children, and 
every leaf node is of the same depth. An 
MTS (m:t), (where m> 3, t> 1) graph of 
degree d has the following properties: 

1. There are m identical CTs of depth 

(/-l). 

2. The roots of m CTs are intercon¬ 
nected to form a ring. 

3. For each level (t-1), each node is 
connected to other nodes at level (t- 1), 
and there is at least one cycle containing all 
the (t - l)-level nodes. 

An example of an MTS(4:3) is shown in 
Figure 4. 

Average distance and communication 
links. There is no known closed-form for¬ 
mula for obtaining the average distance 
for an MTS. Arden and Lee have given a 
table for a number of values of n and these 
have been used in the plots of Figures 7 
and 8. The maximum number of ports on 
each computer remains constant (four). 

Routing algorithm and fault tolerance. 
No routing algorithm has been given by 
the authors. The network has redundant 
paths, and is hence tolerant of single 
faults. 

Expansion capability. Although this is a 
tree structure, it is not easily extensible in 
small increments. 


Bus-oriented structures 

We now analyze two representative bus 
structures with regard to the criteria 
described earlier. 

The spanning bus hypercube. The span¬ 
ning bus hypercube connection is similar 
to the mesh connection. 8 There are N 
computers connected on several buses. 
Each computer is connected to D buses 
that span each of the D dimensions of the 
hypercube space. Nodes that have all their 
coordinates—except the i th —the same are 
connected to the i lh bus. Figure 5 shows a 
3 3 spanning bus hypercube structure. 

Average distance. The average distance 
for the spanning bus hypercube is given by 
equation (4), the alpha structure formula, 
because of the similarity of the addressing 
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schemes between these networks. 

The number of buses used is 8 D W D ~ 1 . 

Routing algorithm and fault tolerance. 

Wittie 8 gives the routing algorithm for 
this network. A single fault in a bus can be 
tolerated by such networks. 

Expansion capability. Spanning bus 
hypercube structures may be expanded by 
increasing D or W. Increasing W has the 
advantage of not requiring fresh ports in 
each computer. 

Beta networks. The beta structure 4 is of 
the same topology as the alpha structure. 

However, a link in the alpha structure is 
substituted for a node (computer) in the 
beta. The node of an alpha network is a 
bus in a beta structure. Figure 6 is an ex¬ 
ample of a beta network. 

Average distance. There exists no 
known closed-form relation for directly 
computing the average distance of such a 
network. The plots of Figures 7 and 8 were 
obtained by numerical methods. 

Communication links. The number of 
buses is given by W D . The number of 
nodes is given by 

W D (W- 1) 

N= -i--- (7) 

2 

Figure 7. (a) Average distance (link structures) versus number of nodes, (b) Average 
(continued on p. 32) distance (bus structures) versus number of nodes. 
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Figure 8. (a) Normalized average distance (link structures) versus number of nodes, (b) Normalized average distance (bus structures) 
versus number of nodes. 


Routing algorithm and fault tolerance. 
The routing procedure is simple and simi¬ 
lar to that of the spanning bus hypercube. 
Beta networks are also fault tolerant. 


Expansion capability. An expansion of 
the beta network does require rerouting of 
the network, but the number of ports de¬ 
manded of each computer remains fixed at 


Figures 7 and 8 show plots of the aver¬ 
age distance and normalized average dis¬ 
tance vs. the number of computers for 
these networks. Among link structures, al¬ 
pha networks have the smallest average 
distance. The next best structure is the 
MTS, followed by the CCC structure. The 
MTS has the best normalized average 
distance. However, the routing poses a 
significant hurdle to its performance. The 
CCC is the next best and, together with its 
simple routing algorithm and its fault 
tolerance, looks attractive indeed. 

In the case of bus structures, the beta 
network possesses smaller average dis¬ 
tance, but its normalized average distance 
is larger and also increases at a faster rate 
than the spanning bus hypercube. 

Table 1 summarizes the important prop¬ 
erties of these interconnection schemes. 
Note that the formulae given therein for 


the average distances are empirical and ap¬ 
proximate, and to be used for comparison 
only. The term message density is defined 
as 

Avg. Dist. X no. of nodes 

Mess. Dens. =- 

Total no. of links 

As was mentioned earlier, no concrete 
conclusion can be drawn at this stage as to 
the relative merit of any scheme based on 
these figures alone. For example, the CCC 
seems to be a reasonable choice from a 
consideration of only the average dis¬ 
tance, but from an application viewpoint 
the alpha structure is the most versatile, as 
is shown later in a simulation study. 

Mapping and 
scheduling issues 

Suppose we have at hand a computa¬ 
tional task and, to perform it, we are also 
given a suitable algorithm to be used. In 
addition, assume this algorithm has been 
divided into some number of subtasks in a 
way that some of these subtasks may be 
run concurrently. As these subtasks run 
(on the different processors), they may 
need to exchange data amongst them¬ 
selves, and it may not be possible to start 
the execution of one subtask before the 
completion of some other subtasks. If we 


can estimate the extent of this data ex¬ 
change, i.e., communication between sub¬ 
tasks (see, for example, reference 5), and 
their data dependencies, then we can esti¬ 
mate the general behavior of the algorithm 
on the system. The scheduling problem is: 
How does one find an optimum allotment 
of these subtasks among the processors so 
that the maximum possible speedup (or, 
equivalently, some other performance 
parameter) may be achieved? For exam¬ 
ple, if two subtasks exchange data fre¬ 
quently, they should be allotted to two 
processors that are adjacent, i.e., directly 
connected to one another. 

So, on one hand we have the several 
subtasks and their interrelationships with 
respect to data dependency; and on the 
other, we have the many (not necessarily 
identical) processors, with their interrela¬ 
tionships, i.e., interconnection scheme. 
We now need to “map” one on the other. 
In a most general purpose computer, no 
information will be available beforehand 
on the nature of the tasks to be performed 
on it, so the mapping described above 
must be done at runtime, dynamically, as 
subtasks are created. The time spent on 
this mapping will contribute to the total 
time that it takes to complete the task. This 
mapping time is not negligible, and may 
significantly detract from the performance 
of the system, especially in real-time appli¬ 
cations, where time is of the greatest im- 
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Table 1. Properties of interconnection schemes. 


Ports/node 



Average 

distance 

(link 

structures) 
or ports on a 
bus (bus 
structures) (P) 

Normalized 

average 

distance 

(L) 

Message 

density 

Number of 
links 
(buses) 

Fault 

tolerance 

(link 

failures) 

Fully connected 
network 

1 

N -1 

N 

N 

(N 2 -N) 

N -1 

Ring 

(bidirectional) 

(N +1)/4 

2 

(N +1)/2 

(N +1)/4 

N 

2 

Cube 

connected 

cycles 

=0.8 log 2 N 
-2.4 

3 

=2.4 log 2 N 
-7.2 

5D/4 

3N 

2 

2 

Alpha 

=k log 2 N + 0.2 
k=0.3 to 0.5 

D(W — 1) 

D(W - 1)L 

2L 

D(W- 1) 

ND 

2 

D(W-1)-1 

Hypertree 

= 1.1 log 2 N 
-0.7 

4 

=4.4 log 2 N 
-2.8 

L 

2 

=2(N -1) 

3 

MTS 

= log 2 N-2 

3 

=3 log 2 N -6 

2 log 2 N -4 

- 

2 

Single global 
bus 

1 

N 

N 

N 

1 

N — 1 

Spanning bus 
hypercube 

=k log 2 N + 0.2 
k=0.3 to 0.5 

W 

=Wlog 2 N + 0.2W 
k=0.3 to 0.5 

W 

DW 0 - 1 

W-1 

Beta 

=k log 2 N + 0.25 
k=0.30 to 0.37 

D(W — 1) 

D(W — 1)L 

L 

W D 

D(W — 1) - 1 


portance. The performance parameter to 
be optimized could be just the total execu¬ 
tion time, or a weighted combination of 
execution and communication times, or 
channel and processor utilization. Numer¬ 
ous authors have considered the problem 
of allocating noninteracting tasks in a dis¬ 
tributed environment. They have not con¬ 
sidered the effects of data dependency or 
communication amongst these tasks. But 
in a multiprocessor environment, inter¬ 
processor communication overheads play 
an important part in determining the per¬ 
formance of the system. 

An optimal assignment of subtasks, or 
modules, to a two-processor system has 
been considered by Stone, 11 in which the 
cost of interprocessor communication has 
been taken into account, in addition to the 
communication and other collective costs. 
The basic idea used by Stone is to apply a 
maximal-flow algorithm to the graph 
model of a modular program, i.e., one in 
which each module is represented by a 
node and the weight on the edge connect¬ 
ing two nodes represents the cost of an in¬ 
termodule reference when the two nodes 


(or modules) are assigned to different 
computers. Each cutset of this graph parti¬ 
tions the graph into two disjoint subsets, 
and each subset could be assigned to each 
processor such that the weights of the 
edges comprising the cutset (which ac¬ 
count for all costs) could be minimized. 
This, in turn, will minimize the total run¬ 
time. Stone also provides a way of extend¬ 
ing this technique for systems with more 
than two processors. 

A more complete solution to this issue 
for an arbitrary number of processors was 
provided by Bokhari. 12 His method as¬ 
sumes that the intermodule communica¬ 
tion requirements (which form a prece¬ 
dence relationship) could be represented 
by a tree-like structure. The method then 
uses a dynamic programming approach, 
and minimizes the sum of execution and 
interprocessor communication costs for 
an arbitrarily connected distributed 
system. 

Tilborg and Wittie 13 introduced anoth¬ 
er method called wave scheduling, which is 
applicable to a large homogeneous multi¬ 
computer system. The method assumes 


that there is a hierarchical level of control 
in the form of a tree (although the comput¬ 
ers themselves need not necessarily be con¬ 
nected in a tree-like form). It also assumes 
that any task can be executed on any one 
of the processors, and that all cooperating 
tasks form a task force, and that these are 
known a priori. A task force needing a 
specific number of nodes is entered in a 
queue at any node, and the hierarchical 
control at the root of the subtree schedules 
the enqueued task forces that are no larger 
than the number of nodes in the subtree. 
Tilborg and Wittie have observed that 
decentralized wave scheduling works well 
with at low to moderate levels of work 
load and its efficiency is comparable to 
that of centralized scheduling. 

There are several other scheduling and 
load balancing strategies advocated by 
various researchers. But these efforts are 
limited to scheduling of noninteractive 
and independent tasks on multiprocessors 
of distributed systems, where the major 
concern has been optimization of execu¬ 
tion times, and the appropriate placement 
of distributed databases. As applied to the 
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Figure 9. Flowchart of the dynamic-scene-analysis (DSA) algorithm. 


architecture we are discussing, the crucial 
issues of data dependency between sub¬ 
tasks and the interprocessor communica¬ 
tion overhead has been neglected. 

Bokhari 12 showed that when assigning 
tasks to the processors, pairs of tasks, or 
modules, that need to communicate with 


each other should be placed, if possible, 
on processors that are directly connected. 
The property that characterizes such an as¬ 
signment is known in graph theory as the 
cardinality of the mapping. Cardinality re¬ 
fers to the number of data transfers of the 
communicating subtasks falling upon 


physically or directly connected proces¬ 
sors. In other words, it gives a number in¬ 
dicating how well the algorithm has 
mapped on the architecture in a physical 
sense. It has been shown 12 - 14 that the 
mapping problem falls into a class of in¬ 
tractable problems, called NP-Complete. 
In order to solve the allocation problem 
with the expenditure of reasonable effort, 
some approximations have to made and 
some heuristics employed. Furthermore, 
if some of the typical algorithms that will 
be used are known previously, then the 
various attributes of the subtasks can be 
estimated and this mapping can be done 
before the actual runtime of the algo¬ 
rithm. This is called static allocation. 
Many real-time applications can be easily 
served by using static allocation, and, as 
we will see later, pipelining. 

The heuristic employed by Bokhari al¬ 
lows pairwise interchange of mapped 
nodes. The exchange that leads to the 
maximum increase in cardinality of the 
mapping is selected. The rationale behind 
the optimization of cardinality is to re¬ 
duce the communication overhead in in¬ 
completely connected systems of multi¬ 
computers. 

Bokhari’s work, though important, has 
some shortcomings. It assumes the proces¬ 
sors are identical and that the channel 
bandwidths are the same for all the chan¬ 
nels. No consideration is given to the 
amount of computation to be done at each 
node, and the amount of data to be trans¬ 
ferred along each connecting edge. 

Some of these issues have been ad¬ 
dressed by Pathak. 14 The heuristic he 
employs is the one known as the greedy 
heuristic. For each node, the algorithm 
looks at the node’s immediate surround¬ 
ings and obtains the optimal mapping, in 
an attempt to eventually achieve a global 
optimization. The algorithm makes use of 
two graph theoretic constructs called the 
Computation Flow Graph and the Com¬ 
putation Resource Graph. It is common 
practice to model the software for parallel 
machines in the form of directed graphs 
with directed edges representing the data 
dependencies, and other parameters being 
associated with each node and the con¬ 
necting edges. In the same way the proces¬ 
sors and their resources could be modeled 
by graphs. The CFG is a directed graph 
that shows the data dependency or the in¬ 
terrelationships with respect to data ex- 
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Figure 11. Flowchart for suboptimal 
mapping. 


change between the various subtasks. 
Each node of this graph represents a sub¬ 
task and each edge in it has a value equal to 
the amount of data that will need to be 
transferred. The CFG is defined to be 
acyclic. 

The CRG is an undirected graph in 
which the nodes are the processors and the 
edges denote the channel between the two 
adjacent processors. The mapping algo¬ 
rithm accepts these two graphs as input, 
and produces as output the mapping of the 
CFG on the CRG. Each node of the CFG 
can be associated with a level. A node has 
level 1 if it is a source node; i.e., it does not 
need any input data from any other node. 
Nodes that need data from level 1 nodes 
are at level 2, and so on. The algorithm 
works as follows: Allocation starts from 
level 1 nodes. For each level /, a node of the 
CFG of level l is chosen per a criterion that 
selects nodes with the maximum computa¬ 
tion and data communication. A match 
for this node is searched for in the CRG. A 
node of the CRG that would minimize the 


total communication and computation 
time is selected. Once all the nodes at level l 
have been matched, scheduling is con¬ 
tinued for level /+1, and so on, until all 
the nodes of the CFG have been mapped. 
The algorithm assumes that the number of 
processors are at least equal to the number 
of nodes of the CFG. 

Once the mapping is done, a simulation 
program is run that will give an estimate of 
some important parameters that can be 
used to judge the effectiveness of the ar¬ 
chitecture/algorithm combination that 
has been employed. If the results are not 
encouraging, another combination may 
be tried. 

A simple example would serve to il¬ 
lustrate the procedure. 

An application example 

The Dynamic Scene Analysis algo¬ 
rithm 15 provides a method for extracting 
images of moving objects. The algorithm 


works in several stages and thus can be 
pipelined. Recall that the CFG was stipu¬ 
lated to be acyclic. Also, since each sub¬ 
task of the algorithm maps on a unique 
processor, when a processor is done with a 
subtask, it will not be used again in this in¬ 
stance of the algorithm. These two condi¬ 
tions allow for pipelining. Figure 9 shows 
the various stages of the algorithm. The al¬ 
gorithm yields a CFG that is shown in Fig¬ 
ure 10. For a more complete description, 
see reference 13. It is required to find a 
suitable architecture on which the algo¬ 
rithm could be mapped so as to achieve a 
respectable speedup. 

The next stage in the evaluation process 
is to consider possible architectures, and 
by studying the results of the evaluation, 
pick the most suitable one. From Figure 
7(a), which gives a plot of the average dis¬ 
tance, the alpha structure, the CCC, and 
the MTS seem to be reasonable choices. 
Now with each of these schemes, the map¬ 
ping algorithm is run and an allocation is 
made. Next, using the software described 
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Table 2. Simulation results for various architectures. 



Number of 
processors 

Degree 

Cardinality 

Average 

communi¬ 

cating 

distance 

Average 

mapping 

distance 

Channel 

utilization* 

Resource 

utilization* 

Speed 

up* 

Turnaround 

time* 

Alpha 

24 

6 

10 

2.000 

1.833 

1.193 

1.035 

0.955 

1.064 

B-Cube 

16 

4 

8 

2.133 

1.792 

1.025 

0.772 

0.603 

1.383 

B-Tree 

13 

3 

3 

3.282 

3.000 

1.679 

0.837 

0.371 

1.935 

CCC 

24 

3 

4 

3.217 

3.458 

1.641 

0.810 

0.359 

1.985 

Full 

13 

12 

24 

1.000 

1.000 

1.000 

1.000 

1.000 

1.000 

H-Tree 

13 

4 

5 

2.269 

2.417 

1.497 

0.807 

0.407 

1.754 

Mesh 

16 

4 

6 

2.667 

2.583 

1.276 

0.864 

0.639 

1.286 

EAMesh 

16 

4 

6 

2.133 

1.958 

1.229 

0.847 

0.639 

1.317 

Ring 

13 

2 

2 

3.500 

3.292 

1.494 

0.833 

0.491 

1.552 

Star 

13 

12 

3 

1.846 

1.875 

1.839 

0.780 

0.214 

2.990 


•Normalized with respect to fully connected scheme. 

Normalizing factors are 0.0143, 0.7248,6.034 and 1.514, respectively. 


in reference 13, a simulation is done, 
which yields estimates of important pa¬ 
rameters. The results of such a simulation 
are given in Table 2, which compares the 
results for various architectures. The sec¬ 
ond column gives the number of proces¬ 
sors (or computers) The third column 
gives the degree, or the number of proces¬ 
sors connected directly to a given proces¬ 
sor. Column 4 gives the cardinality of 
mapping. The fifth column gives the aver¬ 
age communicating distance between two 
processors (in number of hops). The next 
column gives the average mapping dis¬ 
tance, which is the average data communi¬ 
cation distance of subtasks on the par¬ 
ticular architecture. Column 7 gives the 
channel utilization, and column 8 the re¬ 
source utilization. By utilization we mean 
the proportion of time the item is kept 
busy. The next column (9) gives the speed¬ 
up over a conventional uniprocessor. The 
last column gives the turnaround time, 
which is the total time for execution. Note 
that the last four columns have been nor¬ 
malized so that the fully connected scheme 
has value 1 for these parameters. The com¬ 
puting power and the data transfer rates 
are assumed to be 1 MIPS and 0.5M 
bytes/s, respectively. 

An examination of the table shows that 
the alpha and mesh structures perform 
close to the fully connected, ideal scheme. 
The cube connected cycles scheme that, 
after a study of Figure 7(a), seemed to be a 
reasonable network to use turns out to be a 


rather poor performer in this application. 
If at this stage, it was concluded that the 
results obtained are not satisfactory for 
any scheme, an alternative partitioning of 
the algorithm may be tried out and the 
steps repeated. This iterative procedure is 
depicted in Figure 11. 


T he methodology outlined here serves 
two purposes. One, it provides a way 
of choosing the appropriate archi¬ 
tecture for a class of applications and, 
two, gives a method of determining how 
good this choice was by actually doing the 
mapping of the algorithm on the architec¬ 
ture and performing a simulation of the 
execution. 

We have tacitly assumed so far that the 
algorithms that will be used have somehow 
been already partitioned into their respec¬ 
tive subtasks. At present this partitioning 
must be done by the programmer. On the 
one hand, this has the advantage that it 
forces the programmer to think in a 
“concurrent” way; future algorithms may 
benefit from this way of thinking. On the 
other hand, there is a vast body of pro¬ 
grams that has already been written, and 
which may be speeded up by exploiting 
any inherent parallelism each may possess. 
It would be tedious to rewrite all these pro¬ 
grams. Instead, it would be extremely 
helpful to have an intelligent compiler that 
could extract parallelism from a program 
written for a sequential machine. Already 


some work is being done in this direction. 
But this is not a trivial task. Parallelism 
may exist in terms of a single do loop, or it 
may be that an entire subroutine may be 
executed in parallel with others. In other 
words, the granularity 16 is variable. 

By incorporating such a compiler in the 
flowchart of Figure 11 the whole mapping 
process may be automated to yield an opti¬ 
mum or near-optimum allocation after a 
few iterations. The (appropriately named) 
B-HIVE project is a nascent multicomput¬ 
er project at North Carolina State Univer¬ 
sity. 17 Here the ideas contained in this 
article have been incorporated in a 
24-computer network, using the alpha in¬ 
terconnection scheme. Each node (or 
computer) consists of two processors: an 
Application processor that actually exe¬ 
cutes the application program, and a 
Communication processor that takes care 
of the details of sending and receiving 
data, routing, etc. This hierarchical con¬ 
struction of each node serves to keep sepa¬ 
rate the two logically different functions. 
The philosophy behind the B-HIVE proj¬ 
ect is to build a functional MCS using a 
“no-frills” approach. It is hoped that the 
hands-on experience we gain from such a 
working system will prove invaluable in 
future designs. □ 
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This experimental run¬ 
time package 
combines the 
capabilities of Ada 
with the flexibility of 
loosely coupled 
networks to gain 
advantages in 
throughput 
reconfigurability, and 
error recovery. 
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T he Distributed Ada Run-time Pack¬ 
age, or DARP, is a key component 
of a broader project to produce a 
high-quality Ada language system for pro¬ 
gramming a loosely coupled, distributed 
network of computers. The goal of the 
overall project is to provide a practical 
Ada system targeted to an instrumented, 
user-controllable, reconfigurable, distrib¬ 
uted operating system running on a large 
number of processors (see Figure 1). In¬ 
tended as a tool for conducting research in 
distributed systems, the language system 
demonstrates that Ada can be correctly 
and efficiently implemented on loosely 
coupled systems. 

By loosely coupled, distributed system 
we mean any configuration of processors, 
memories, and links in which each proces¬ 
sor has a designated local memory that it 
can access in significantly less time than it 
can access either shared memory or the 
local memory of other processors. Typi¬ 
cally, such systems have a high bandwidth 
communication link between processors 
but little or no shared memory. The key to 
efficient use of these systems is to exploit 
low-cost intraprocessor communication 
and to avoid higher cost interprocessor 
communication. 

Loosely coupled systems offer several 
potential advantages over shared-memory 
systems: greater throughput, easier scaling 
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to larger configurations, and error recov¬ 
ery capabilities. Greater throughput is 
possible because independent tasks are not 
competing for access to shared memory 
and because the number of processors that 
can be accommodated in a system is not 
bounded. Similarly, with the appropriate 
software, loosely coupled systems should 
be scalable to any number of processors. If 
the number of processors can be dynami¬ 
cally altered, then it is possible to increase 
throughput by taking advantage of added 
processors. Error recovery is possible if 
the operating system and the application 
program together can detect and isolate 
failed components and then reconfigure 
the system for the most effective use of the 
remaining components. 

Development of both application and i 

operating system software is more dif¬ 
ficult on loosely coupled systems than on 
conventional systems. The absence (or 
high overhead) of shared memory means 
that the traditional methods for multi¬ 
programming and multitasking in uni¬ 
processors and in shared-memory multi¬ 
processor systems are not applicable. 

Thus, the issues of allocation of tasks and 
shared data, of intertask communica¬ 
tion, and of distributed versus central 
control take on new influence in overall 
system performance. The desire to ex¬ 
ploit the inherent scalability and recon- 
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Figure 1 . Ada system targeted to distributed operating system (DARP) for a loosely 
coupled network. 


figurability of loosely coupled hardware 
systems generates additional require¬ 
ments for reconfigurable, scalable, dis¬ 
tributed control and for fail-soft and fail¬ 
safe software. 

Most of these added requirements fall 
on the target operating system. Optimal 
solutions to these problems are outside the 
scope of our effort in developing DARP. 
Instead, we have designed DARP as a re- 
configurable, distributed-target system 
with sufficient “handles” to enable users 
(in this case, distributed-processing re¬ 
searchers) to interrogate, tune, and adjust 
it. DARP gives the user access to the dy¬ 
namic state of the system, permits the user 
to control the allocation of tasks and data 
to processors, and generalizes certain Ada 
tasking features that would otherwise re¬ 
strict the scope of distributed-processing 
research. The system will not be fail-soft 
or fail-safe, but it will provide sufficient 
information and control that fail-soft and 
fail-safe applications can be built. 

The Ada compiler is hosted on Apollo 
workstations and cross-compiles to a BBN 
Butterfly system. 1 A Butterfly system typ¬ 
ically has from 16 to 256 processors, each 
consisting of an MC68000 processor chip 
and from 256K bytes to 4M bytes of local 
memory. The processors are connected 
through a special switch mechanism, 
which simulates an N X N crosspoint net¬ 
work using only N x ln(N) components. 

The Butterfly system is capable of map¬ 
ping any processor’s memory into the ad¬ 
dress of a given processor, providing the 
appearance of a shared-memory system to 
the user and making interprocessor com¬ 
munication convenient in software devel¬ 
opment. Efficient use of the system, how¬ 
ever, requires that the illusion of shared 
memory not obscure the actual perfor¬ 
mance characteristics of a loosely coupled 
system. 

The Ada language system includes the 
complete compiler front end, a distrib¬ 
uted-target code generator, an instrumen¬ 
tation package, and the Ada run-time 
package. The front end supports all re¬ 
quired Ada features plus the generaliza¬ 
tions needed for distributed-processing 
research. The instrumentation package al¬ 
lows the user to interrogate and record the 
dynamic state of the target system. The 
run-time package takes the form of a dis¬ 
tributed operating system for any Butter¬ 
fly configuration, running on each node in 
the network. 


DARP must deal with a variety of 
unique issues. Each issue introduces pro¬ 
blems in the design and implementation of 
correct and efficient features in the run¬ 
time system. In addition, certain language 
design issues arise from the need for the 
user to be able to specify and control the 
dynamic behavior of the system. For that 
reason we are fortunate to be using Ada, 
which has a number of useful features for 
specifying and controlling task activities. 


Task synchronization 

Ada provides both task synchronization 
and intertask data communication in the 
form of the rendezvous mechanism. 
Rendezvous is the intersection of the con¬ 
trol paths of two tasks that were previously 
executing in parallel. The time at which the 
two paths become one is called a critical 
region. The point of intersection is called 
an entry. To rendezvous, one task must 
call an entry and the other must accept that 
same entry. Entries have arguments that 
act as actual parameters to the calling task 
and as formal parameters to the accepting 
task. (Terminology used here is that of the 
Ada reference manual. 2 ) 

Once a rendezvous is attempted, the 
task remains suspended until rendezvous 
begins or a timeout "occurs. Rendezvous 


begins when the calling task is accepted. 
Timeout occurs when a specified max¬ 
imum time before the beginning of rendez¬ 
vous is exceeded. The length of time the 
task wishes to wait for a rendezvous is 
specified by the task when it attempts to 
accept or call an entry. 

Ada allows a task to attempt to accept 
more than one entry at a time. These si¬ 
multaneous acccept attempts are grouped 
in “select” statements. A select statement 
may attempt to accept any subset of the 
entries declared by the task containing the 
select. The first entry called is allowed to 
rendezvous. If more than one entry is 
called before the select statement is 
reached, any one of them may be ac¬ 
cepted. If no entry is called prior to the se¬ 
lect, rendezvous will be with the first entry 
called. In Ada a task may call only one en¬ 
try at a time. 

Because DARP is intended for distrib¬ 
uted-processing research, some of the syn¬ 
chronization restrictions imposed by the 
Ada language have been removed. Most 
important of these is the lack of symmetry 
in the Ada rendezvous. This restriction 
precludes multiple providers of the same 
service; that is, Ada does not allow two 
tasks to accept the same entry. The asym¬ 
metry arises from three Ada restrictions: 
multiple entry calls are not permited in the 
same select statement; an entry call cannot 
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Table 1. Task synchronization messages. 


as an intermediary for other message traf¬ 
fic (parameter passing, for example). 


Name 

Rendezvous request 
Accept enable 

Call enable 
Call acknowledge 
Resume caller 
Timeout request 
Timeout accepted 
Tasking exception 

Delete from queue 


Source 

Requesting task 
Entry manager 

Accepting task 
Calling task 
Accepting task 
Requesting task 
Entry manager 
Calling or 
accepting task 
Requesting task 


Destination 
Entry manager 
Accepting task 

Calling task 
Accepting task 
Calling task 
Entry manager 
Requesting task 
Accepting or 
calling task 
Entry manager 


Parameter 
Call/accept vector 
Entry name, 
calling task 
Entry name 
In parameters 
Out parameters 
(Implicit) 

Yes or no 
(Implicit) 

(implicit) 


appear in the same select as an accept; and 
entries can be accepted only by the task 
that declares them. 

To overcome these restrictions, we have 
generalized the rendezvous mechanism to 
be symmetric, allowing a given task to call, 
and simultaneously accept, any subset of 
the entries visible to it. All transactions re¬ 
quired during rendezvous are described in 
terms of a fixed set of messages and ac¬ 
tions to be performed upon receipt of each 
message. The same messages are used 
whether the rendezvous is between pro¬ 
cessors or within a particular processor. 
To allow maximum control of load place¬ 
ment and observability of the system, the 
responsibility for rendezvous manage¬ 
ment is distributed rather than assigned to 
the processor hosting the accepting task or 
concentrated in a central system sched¬ 
uler. Finally, unnecessary sharing of ope¬ 
rating system functions is kept to a mini¬ 
mum. Just as it is reasonable in a system 
having several parallel processors to have a 
scheduler for each processor, the tasking 
activities of the system should be parti¬ 
tioned into as many independent manage¬ 
ment groups as possible so that the effort 
can be distributed and the parallelism 
exploited. These management groups, 
called entry equivalence classes, vary in 
number and composition from program 
to program. 

Entry equivalence classes. Like all ob¬ 
jects in Ada, entry visibility is arranged 
hierarchically, starting with the scope in 
which it is declared and spreading down¬ 
ward to all subordinate scopes. Unlike 
other objects in Ada, however, there are 
additional restrictions on where entries 


may be declared. An entry may be de¬ 
clared only in a task and only in the task 
allowed to accept that entry. This incon¬ 
sistency is the root of the asymmetry of 
Ada rendezvous; removing it also removes 
most of the asymmetry. With the elimina¬ 
tion of the close coupling between the en¬ 
try and a particular accepting task, a new 
and more general structure is revealed. 

Each entry can have its own indepen¬ 
dent rendezvous manager, provided that it 
does not appear in the same select state¬ 
ment with another entry. That is, we can 
define an equivalence relation among en¬ 
tries, making two entries equivalent, if 
there is a task waiting for both entries in 
the same select statement. With the Ada 
restrictions, entries of two different tasks 
can never appear in the same select and 
need not be in the same equivalence class. 
Thus, a separate manager can be asso¬ 
ciated with each task, as in the STC-Ada 
System. 3 

Without the Ada restriction, an equiva¬ 
lence class can grow arbitrarily large if 
there is a wide variety of entry combina¬ 
tions in multi-way select statements. On 
the other hand, an entry that is called and 
accepted by every task in the system can 
have its own class if it is never called or ac¬ 
cepted in combination with other entries. 
Every entry equivalence class is assigned to 
a particular processor and administered by 
a unique task within that processor. This 
task, the entry equivalence class manager, 
receives request messages from tasks ask¬ 
ing to call or accept some subset of the en¬ 
tries of its class. It coordinates the estab¬ 
lishment of rendezvous but does not serve 


Entry equivalence class manager. At the 
highest level the entry equivalence class 
manager receives rendezvous request mes¬ 
sages from tasks that are calling or accept¬ 
ing entries in its equivalence class. It initi¬ 
ates rendezvous at the appropriate time by 
sending messages back to the requesting 
tasks. There are three parts to this scheme: 
the purpose and content of the messages, 
the state information and data structures 
contained within the manager, and the ac¬ 
tion associated with the transmission and 
reception of these messages. 

Only nine types of messages (see Table 
1) are required to implement rendezvous 
on a distributed system. 4 Each message 
type has a name and a destination as well 
as a number of parameters, which can be 
as simple as the name of the task that sent 
the message or as involved as the list of 
parameters supplied to the critical region 
of an accept statement. The requesting 
task may be calling, accepting, or some 
combination of these. The principle data 
structure of rendezvous is the call/accept 
vector. 

Call/accept vector. With the Ada re¬ 
strictions a task can simultaneously at¬ 
tempt to accept any subset of the entries of 
an equivalence class. With the symmetric 
rendezvous it can also simultaneously at¬ 
tempt to call any subset of the entries. The 
only constraint imposed on this generality 
is the requirement that the intersection of 
the calling and accepting entries of a given 
select statement be disjoint. That is, a task 
is not permitted to rendezvous with itself. 
The call/accept vector is an encoding of 
the subset of entries that a given task is at¬ 
tempting to call or accept. 5 The following 
type declaration gives a simple representa¬ 
tion of the call/accept vector: 
typec_a_vector(number_of_entries:integer)is 

calling :array(l. .number_of_entries) 
of boolean; 

accepting :array(l. ,number_of_entries) 
of boolean; 

end record; 

Assuming a mapping has been estab¬ 
lished between the entries in an entry 
equivalence class and the integers 1 to 
number_of_entries, a task T would build 
a call/accept vector Fas follows: V.call¬ 
ing (i) will be true if and only if Tis at- 
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tempting to call E i} and V.accepting(i) 
will be true if and only if 7"is attempting to 
accept Ej. A tasking exception will be 
raised in T if for any i both V.calling(i) 
and V.accepting(i) are true. The vector, 
together with the task name T, would then 
be sent to the manager of the entry equiva¬ 
lence class as the parameters of a rendez¬ 
vous request message. 

When an entry equivalence class man¬ 
ager receives a rendezvous request mes¬ 
sage, two things can happen: the request 
will be honored immediately with the in¬ 
itialization of a rendezvous, or the request 
will be placed at the end of a list of existing 
requests. To make this decision, the 
manager compares the newly arrived 
call/accept vector to all those it has 
already received. This comparison pro¬ 
ceeds sequentially, starting with the oldest 
existing request and working toward the 
newest. Searching the call/accept vectors 
of an equivalence in chronological order 
of arrival satisfies the Ada requirement for 
first-in-first-out queueing of requests at a 
given entry. Similarly, the oldest request 
that can be satisfied, will be. This ensures 
fairness by precluding permanent block¬ 
ing, which is allowed by Ada. The ordered 
queue of outstanding rendezvous requests 
for a given entry class is represented by an 
array: 

request_q: array( 1. .queue_size)of 

c_a : c_a_vector(class_size); 

requestor :task_name: 

end record; 

The manager compares request_q (/). 
cua.calling with V.accepting and re¬ 
quest _q(i). cja. accepting with V. calling 
in chronological order for each /' from 1 to 
queue^size. A true in corresponding posi¬ 


tions of either pair of vectors indicates that 
a rendezvous is possible between T, the 
task that sent the rendezvous request 
message, and the task requestuq(^.re¬ 
questor. Should no match be found, the 
incoming request will be added to the end 
of request_q. This process is illustrated in 
the following program fragment: 

-Receive a Rendezvous Request message 

-with c_EL_vector V from task T. 

for i in 1 ,.queue_jsize loop 
for j in l..class_size loop 
if request_q(i).c_a.calling(j) 
and V.acceptingG) then 

-Send Accept Enable message to 

-task T along with name of entry be- 

-ing accepted, E j, and name of call- 

-ing task, request_q(i).requestor. 

-Remove request_q(i) from request 

-Exit entry equivalence class 

-manager. 

if request_q(i).c_a.accepting(j) 
and V.callingG) then 

-Send Accept Enable message to 

-task request_q(i).requestor along 

-with name of entry being accepted, 

-E j, and name of calling task, T. 

-Remove request_q(i) from request 

-queue. 

-Exit entry equivalence class 

-manager. 

end if; 
end loop; 
end loop 

queue_size: = queue_size +1; 
request_q(queue_jsize).c_a: = V; 
request_q(queuejize). requestor: = T; 

-Exit entry equivalence class manager. 

In practice, the comparison often can be 
done with a single-integer-operation per 
requestjq element. If the class_size is no 
more than half the number of bits in the in¬ 


teger of the target machine, then the entire 
call/accept vector can be encoded in a 
single integer. For purposes of the com¬ 
parison, the accepting and calling portions 
of the arriving vector are interchanged. 
The comparison is accomplished by form¬ 
ing the bit-for-bit conjunction (inclusive 
or) of the interchanged arriving vector and 
an element of the requests and then 
testing the resulting integer for nonzero. 

The two scenarios below demonstrate 
the rendezvous process and illustrate how 
little the entry equivalence class manager is 
involved. The manager acts only as a 
broker to bring the two requesting tasks 
together; the actual rendezvous is executed 
without the manager’s involvement. In the 
first scenario both tasks wait until rendez¬ 
vous is possible; in the second scenario one 
of the rendezvous partners will timeout 
(give up) before rendezvous is possible. 

Scenario 1: Normal rendezvous. For 
rendezvous to take place (see Figure 2), 
complementary rendezvous request mes¬ 
sages must arrive at the manager, indicat¬ 
ing the desire of one task to call a par¬ 
ticular entry and of the other task to accept 
that entry. The manager initiates the ren¬ 
dezvous by sending an accept enable mes¬ 
sage to the accepting task. The accept 
enable message includes the name of the 
calling task as well as the name of the ac¬ 
cepted entry. No further intervention by 
the manager is required. The accepting 
task sends a call enable message to the call¬ 
ing task, telling it which task and entry to 
rendezvous with. The calling task re¬ 
sponds by sending the input parameters to 
the critical region in a call acknowledge 
message and then suspending its own exe¬ 
cution. When the accepting task receives 
the call acknowledge message, it begins 
execution of the critical region of the 
rendezvous, and then it returns any output 
parameters to the calling task in a resume 
caller message. When the calling task re¬ 
ceives the resume caller message, it con¬ 
tinues its normal execution and the rendez¬ 
vous is complete. 

Scenario 2: Timeout. For a variety of 
reasons, we take the position that timeouts 
must be the responsibility of the individual 
calling and accepting tasks (more precise¬ 
ly, a timing task within their local pro¬ 
cessor). If timeouts were processed by a 
central controller, by the entry equiva- 
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lence class manager, or by any other 
foreign (i.e., in another processor) task, 
there would be a significant increase in the 
number and size of interprocessor control 
messages. Furthermore, in a distributed 
system there is no guarantee that clocks in 
different processors will agree on the time 
or even on the rate at which time passes. 
Finally, if there were a failure in the 
foreign processor to which the timeout 
function was delegated, the timeout would 
never be reported. 

If timeouts are determined locally but 
the rendezvous manager is in a foreign 
processor, conflicting decisions and race 
conditions might arise. The DARP design 
avoids such situations by requiring that 
any timeout be confirmed by the entry 
manager prior to being reported to the re¬ 
questing task. If the entry manager has 
already initiated the rendezvous by send¬ 
ing the accept enable to the accepting task, 
then the timeout request will be ignored 
and a negative timeout accepted sent to the 
requestor. Otherwise, the requesting 
task’s call/accept vector will be removed 
from the request_q and the timeout ac¬ 
cepted. The entry class manager is able to 
determine that it has already initiated the 
rendezvous only by the absence of a vector 
from the requesting task in its request_q. 
The message interactions for timeout are 
illustrated in Figure 3. 

Exceptions and termination. Another 
issue to be considered is the possibility that 
while engaging in a rendezvous, a task or 
its rendezvous partner may become abnor¬ 
mal. It is also possible, through the ter¬ 
minate select alternative, that a rendez¬ 
vous attempt could cause a task to end its 
own execution. The existence of the ter¬ 


minate select alternative in Ada greatly 
complicates the entry equivalence class 
manager and the rendezvous mechanism. 
The control of an abnormal task engaging 
in rendezvous, on the other hand, is rela¬ 
tively simple and requires only one addi¬ 
tional message type. 

Should a task become abnormal after 
transmitting a rendezvous request mes¬ 
sage, it can receive either an accept enable 
message from the manager (indicating the 
task is the acceptor of an entry call) or a 
call enable message from a rendezvous 
partner (indicating the task is the caller of 
some entry). In either case the task must 
send a tasking exception message to the 
task named in the parameter of the accept 
enable or call enable message. If a task be¬ 
comes abnormal after receiving the call ac¬ 
knowledge (during the critical region of 
the accept), it sends a tasking exception 
message, rather than the normal resume 
caller message, to its partner. Having 
propagated the tasking exception, it is free 
to end its execution as dictated by the Ada 
rules for task completion and exception 
handling. 

The terminate select alternative of Ada 
has little, if any, utility but imposes a great 
price in implementation complexity. 6 Five 
additional messages are required to ac¬ 
commodate it. Several entry equivalence 
class manager and task dynamic control 
functions must be combined. Briefly, to 
select a terminate alternative, a task must 
inform the manager of its intent to termi¬ 
nate, using the rendezvous request mes¬ 
sage. The manager must communicate 
with the task’s master scope to determine 
whether termination is possible (i.e., 
whether all of the task’s siblings are termi¬ 
nated or waiting at terminate alternatives). 


If the master scope indicates termination is 
possible, the manager must check to see if 
a rendezvous began between the arrival of 
the rendezvous request message and the 
master scope’s reply. If so, the manager 
informs the task master scope of the task’s 
change in status from waiting at a ter¬ 
minate alternative to activated. Otherwise, 
the manager informs the task that it is ter¬ 
minated and removes its call/accept vector 
from request_q. 

Task dynamics 

Task dynamics involves the creation of 
a task, the synchronization of its elabora¬ 
tion, the management of its local storage, 
and its orderly removal from the system 
when its mission is complete. The pro¬ 
grammer is seldom aware of a task’s dy¬ 
namics because most of the operations are 
called implicitly and often occur in the de¬ 
clarative portions rather than the state¬ 
ment portions of programs. 

A simple diagram of state transition in 
the life of a task is shown in Figure 4. In 
the “created” state a task’s visible parts 
can be seen, but the elaboration of its de¬ 
clarative parts has not begun. In Ada this 
means the task’s entries are callable. Once 
created, a task begins executing its declara¬ 
tions during create time or during the elab¬ 
oration of the declaration of its creating 
scope, whichever occurs later. After the 
creating task signals the end of its declara¬ 
tive part, the task is considered active and 
can proceed with the parallel execution of 
its statements. Our discussion here 
assumes the Ada semantics for task dy¬ 
namics (see Table 2). 

The completion of the body of each de¬ 
pendent task and of the body of the master 
scope marks a common synchronization 
point between the master scope and all its 
dependents. Because the master scope 
cannot deallocate the storage for its sib¬ 
lings and terminate itself until its depen¬ 
dents terminate, a dependent terminated 
message is sent to inform the master as 
each dependent completes execution. 
When all its siblings are also terminated 
(or waiting at terminate select alterna¬ 
tives), the master sends deallocate task 
messages, permitting all the dependent 
tasks to delete their visible parts and sur¬ 
render their storage. 

To create a task, the creating processor 
need know only the task executing the 
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create, the new task’s master scope, and 
the location of the code for the new task. 
The new task will be allocated, but will not 
necessarily be visible, in the scope of its 
master. Once the new task is created, the 
creating processor gives the creating task 
access to the new task by sending it a point¬ 
er to the new task in a create acknowledge 
message. The creating processor also 
sends an add dependent message to the 
master scope so it can know which tasks to 
include in its list of dependents. 

The resume task message signals the 
completion of the creating task’s declara¬ 
tive part. After the creating task has 
elaborated its declarations, the depen¬ 
dents are free to begin execution of their 
declarative parts and bodies. 

When a task finishes execution of its 
body, it uses the dependent terminated 
message to inform its master scope of its 
termination. The master scope then re¬ 
moves the dependent named in the depen¬ 
dent terminated message from its list of ac¬ 
tive dependents. When the list is empty, 
the master scope sends deallocate task 
messages to all its dependents. 

The abort task message is sent to all 
tasks named in an abort statement. Ada 
semantics require that the aborting task 
not proceed until the specified tasks are 
aborted. Thus, an acknowledgment is re¬ 
quired and takes the form of the abort ac¬ 
knowledge message. 



Shared variables 

A shared variable is any variable used by 
more than one task. Without global analy¬ 
sis of programs, it must be assumed that a 
variable is used by all tasks to which it is 
visible. Thus, in many systems, all vari¬ 
ables visible to multiple tasks must be 
treated as shared variables. This is particu¬ 
larly expensive when programs are written 
in languages that couple the allocation and 
visibility of variables. In many program¬ 
ming languages own variables must be de¬ 
clared globally; consequently, they be¬ 
come visible to all tasks and thus appear to 
be shared variables. Ada eliminates much 
of this problem by providing global alloca¬ 
tion of variables within the body of pack¬ 
ages and tasks without their being visible 
outside the package. 

For safe and correct use of shared varia¬ 
bles, there must be synchronization be¬ 
tween the using tasks. Typically, within 


fable 2. Task dynamics messages. 

Name 

Source 

Destination 

Parameters 

Create task 

Creating task 

Creating processor 

Master scope, 




code (task type) 

Create acknowledge 

Creating processor 

Creating task 

Task pointer 

Add dependent 

Creating processor 

Master scope 

Dependent task 

Resume task 

Creating task 

Suspended task 

(Implicit) 

Dependent terminated 

Completed task 

Master scope 

(Implicit) 

Deallocate task 

Master scope 

Completed task 

(Implicit) 

Abort task 

Aborting task 

Abort victim 

(Implicit) 

Abort acknowledge 

Abort victim 

Aborting task 

(Implicit) 


each task there is a sequence of operations, 
called a critical region, during which the 
shared-variable value cannot change. If 
another task alters the value of the shared 
variable during a critical region, the com¬ 
putation may be erroneous. A simple ex¬ 
ample occurs when two tasks both attempt 
to increment a shared variable. Each ac¬ 


cesses the variable, adds 1, and stores the 
result back in the variable. If both tasks 
access the variable before either stores the 
incremented result, the variable will be 
incremented only once rather than twice as 
intended. 

Even uniprocessor and multiprocessor 
implementations with shared memory 
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For a loosely coupled, 
distributed system to 
be efficiently 
reconfigurable, 
resource allocation 
decisions must be 
localized to individual 
processors. 


must have a mechanism for mutual exclu¬ 
sion of access within the critical regions as¬ 
sociated with shared variables. The least 
restrictive (to the user) use of critical re¬ 
gions requires that if any task is in the crit¬ 
ical region to update the shared variable, 
then no other task may be there. On the 
other hand, any number of tasks may 
enter the critical regions simultaneously, 
provided that all are reading and none are 
updating the shared variable. The Ada 
language imposes an equivalent restric¬ 
tion: if a task reads a shared variable be¬ 
tween two synchronization points, then 
the variable is not updated by any other 
task. Likewise, if a task updates a shared 
variable, then the variable is not updated 
or read by any other task. 

These Ada restrictions guarantee that 
local copies of shared variables can be 
maintained between synchronization 
points and that the master copy can be up¬ 
dated only at synchronization points ter¬ 
minating critical regions that update the 
shared variable. 7 This ability to maintain 
local copies becomes essential for efficient 
implementation of shared variables in the 
absence of shared memory. 

Another view of shared variables in a 
distributed system without shared memo¬ 
ry is that a task can update shared vari¬ 
ables if, and only if, the task and the 
variables are in the same processor. Thus, 
in general, during the critical region of an 
update, either the variable must be moved 
to the processor of the task or the task 
must be moved to the processor of the 
variable. The latter can be accomplished 
by creating, within the processor of the 
shared variable, a surrogate task to exe¬ 
cute the updating critical region on behalf 
of the real task. This mechanism is not 


provided in the DARP system as a primi¬ 
tive, but the user can construct it by declar¬ 
ing the surrogate task explicitly and ren¬ 
dezvousing with it. This method, however, 
is applicable only in situations in which all 
shared variables of a given critical region 
are in the same processor. 

In the absence of shared memory, it 
must be possible to copy shared variables 
from processor to processor. The Ada 
shared-variable restrictions allow a copy¬ 
ing technique with minimum overhead: 
Upon entry into a critical region, a shared 
variable is copied to the processor of the 
reading or updating task. Just prior to exit 
from a critical region updating it, the 
shared variable is copied back to its origi¬ 
nal processor. No additional management 
or analysis is required except the critical 
region synchronization itself. There is a 
trade-off between the cost of copying large 
data objects and the synchronization 
overhead on independent partitions of 
that data. The judicious partitioning of 
shared variables reduces both contention 
and copying time. 


Resource allocation 
and reconfiguration 

Resource allocation is the management 
and control of the association between the 
physical and logical components of the 
system. Most important are memory man¬ 
agement and task allocation. A key goal in 
the design of DARP is that it be reconfig¬ 
urable—that is, that we can dynamically 
alter the assocation between physical and 
logical devices. 

There are three primary motivations for 
reconfiguration: dynamic load sharing, 
fail-safe execution, and fail-soft capability. 
Dynamic load sharing, a possibility in any 
multiple-processor system, is the ability to 
redistribute work loads (i.e., tasks and 
data) among processors to increase overall 
system throughput. Fail-safe execution— 
recovery from system component failures 
without loss of information—requires de¬ 
tection and isolation of faulty compo¬ 
nents, as well as the ability to reconfigure 
the system to use the remaining compo¬ 
nents. Fail-soft capability combines dy¬ 
namic load sharing with fail-safe execu¬ 
tion to give priority to the most important 
tasks when the remaining resources are in¬ 
adequate to provide the full functionality 


of the system. In DARP we do not provide 
these capabilities. Instead, we provide fa¬ 
cilities for user-controlled dynamic recon¬ 
figuration of the system, which, in combi¬ 
nation with other system features, can be 
used to develop the higher level, dynamic 
load-sharing, fail-safe, and fail-soft capa¬ 
bilities in user programs. 

For a loosely coupled, distributed sys¬ 
tem to be efficiently reconfigurable, 
resource allocation decisions must be lo¬ 
calized to individual processors of the net¬ 
work. Thus, DARP provides system man¬ 
agement without centralized decision 
making, scheduling, or record keeping. 
Instead, each processor manages its own 
resources, both physical and logical. Sched¬ 
uling is done independently within each 
processor, and each processor allocates its 
own memory without coordination with 
other processors. Each physical device at¬ 
tached to a specific processor has a manag¬ 
ing task within that processor. The manag¬ 
ing task, called an input-output responder, 
acts as an interface between the device and 
any using task. Communication is through 
the normal rendezvous mechanism. 

The binding of tasks to processors is 
specified by an implementation-defined 
pragma. The allocation pragma has two 
arguments; the first designates the task, 
and the second, the processor to which the 
task is allocated: 
pragma allocate (task, processor); 

The task parameter may be a task, an ac¬ 
cess task, a task type, or an access task 
type. In the first two cases, the pragma ap¬ 
plies to the individual task, and in the lat¬ 
ter two cases, to the entire task type. The 
pragma must appear between the declara¬ 
tion of its first argument and the activation 
of the task whose allocation it specifies. If 
multiple allocate pragmas are issued for 
the same task, individual specifications 
take precedence over task type specifica¬ 
tions; otherwise the most recent specifica¬ 
tions take precedence. 

The processor specification in an alloca¬ 
tion pragma can be either a processor 
number or the name of any visible task or 
variable. In the latter case, the designated 
processor is that in which the specified task 
or variable is located. If no allocation 
pragma is given for a task, it will be allo¬ 
cated in the processor of its master. Static 
binding of tasks to processors is achieved 
when the processor specification is a static 
expression. Dynamic binding occurs when 
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the processor number can be computed 
only at run time. 

The binding of tasks to processors is im¬ 
plemented by a single run-time primitive, 
which creates the task and allocates it 
within the designated processor. Calls on 
this function are emitted implicitly by the 
compiler at the point where each task is al¬ 
located. A similar allocation pragma is 
used to specify the allocation of shared 
variables. 

In some systems, it also may be desir¬ 
able to allow migration of tasks between 
processors once the task has been partially 
executed. The feasibility of such migra¬ 
tions is being investigated. There are sever¬ 
al hardware (i.e., instruction set) architec¬ 
tural features that may preclude migration. 
Tasks cannot be moved if their associated 
execution stacks, including subprogram 
return marks, contain absolute memory 
addresses unrecognizable by the operating 
system. It appears likely that migration 
will be possible on the MC68000, but it 
may be too expensive to be worthwhile. 

When migration is not feasible, an alter¬ 
native is to restart the computation associ¬ 
ated with the given task at some earlier 
known synchronization point. For such 
methods to work, tasks and subprograms 
must be guaranteed to act as pure func¬ 
tions—functions whose side effects occur 
at well-defined points in the computation. 
The DARP system accomplishes this by 
implementing all formal parameters with 
copy semantics. That is, all in-out and out 
parameters are copied into the called sub¬ 
program or task at the point of the subpro¬ 
gram or entry call and are copied out only 
when the subprogram or rendezvous has 
been completed without error. If any error 
or exception occurs during the execution 
of the subprogram or critical region, the 
update of the in-out and out parameters 
will not have occurred and, therefore, the 
erroneous computation will affect only the 
state of its local variables. Recovery can be 
made from the point of call. 

Ada requires that “if two tasks with dif¬ 
ferent priorities are both eligible for execu¬ 
tion and could sensibly be executed using 
the same physical processors and the same 
other processing resources, then it cannot 
be the case that the task with the lower 
priority is executing while the task with the 
higher priority is not.” 8 We agree with 
this Ada restriction and interpret it to 
mean that strict priority scheduling is re¬ 


quired within an individual processor, 
may be required among multiprocessors 
of a shared-memory system depending on 
the costs involved, and is not required 
between processors of a loosely coupled, 
distributed system. The DARP design 
provides priority scheduling within each 
processor but not between processors. 
Any requirement for interprocessor-im¬ 
posed priorities would have to be imple¬ 
mented by explicitly specified task syn¬ 
chronization. As anticipated in the Ada 
requirements, priorities cannot be used to 
achieve mutual exclusion. 


Instrumentation 

The DARP design includes an instru¬ 
mentation package that provides a collec¬ 
tion of functions for accessing the dynam¬ 
ic state of the system. Existing timeshared 
systems often collect a variety of informa¬ 
tion on the amount of processor time, in¬ 
put/output time, and other system re¬ 
source allocation associated with a given 
task or program. Although such informa¬ 
tion may be appropriate for accounting 
and cost allocation, it may not be adequate 
for research in distributed systems. Re¬ 
searchers need more detailed data describ¬ 
ing discrete events and system actions un¬ 
related to cost apportioning. 

One way to provide such data would be 
to record a complete history, showing each 
system event and the time of its occurrence. 
To be adequate for general research pur¬ 
poses, an event-recording system must col¬ 
lect a set of fine-grained events, including 
all events related to scheduling, resource 
allocation and deallocation, access to 
shared variables, task synchronization, 
and error propagation. Such a system 
would be very expressive, but it would pro¬ 
duce far too much unneeded data. It also 
would fail to record events within the ap¬ 
plication program that may be important 
to the analysis of the experimental results 
but are unknown to the operating system. 

Instead, DARP’s instrumentation pack¬ 
age provides an event-recording system 
that is fine-grained but controlled by the 
user. Events may be defined by the user or 
by the system. The subset of events to be 
recorded is specified by the user. Each re¬ 
corded event includes its time, the proces¬ 
sor on which it occurred, the task initiating 
it, its name, and any event parameters. 


To minimize the 
overhead of event 
recording, each event 
is recorded locally 
within the processor 
generating it. 


To minimize the overhead of event re¬ 
cording, each event is recorded locally 
within the processor generating it. Because 
each processor has its own record of events, 
the executing processor is implicit in the 
list of events and need not be recorded ex¬ 
plicitly with each event. Each recorded 
event, however, is assigned a sequential in¬ 
teger indicating its chronological order 
among the recorded events of its executing 
processor. This integer can be used to in¬ 
dex events and is recorded with certain in¬ 
terprocessor events to be discussed below. 

Each user-defined event has a name and 
may be associated with any subprogram. 
A pragma is used to specify the association 
between the event name and the subpro¬ 
gram, and to turn the recording of the 
event on or off: 

pragma event(event_name, subprogram. 

name, on_off); 

When the event recording is on, the event, 
time, executing task, and all actual param¬ 
eter values of the subprogram are recorded 
within the executing processor each time 
the subprogram is called. 

All other events that can be recorded are 
defined by the system. System-defined 
events include all intertask and task-to- 
DARP messages and the scheduling of 
tasks within the run queue of each proces¬ 
sor. For system-defined events, the event 
name is the message name. A pragma is 
used to turn recording of the event on and 
off and to determine which events for that 
message are to be recorded: 

pragma event(message_name(parameter. 

associationjist), on_off); 

The parameter assocation list is a list of ex¬ 
pressions of the form id = > exp, where id 
is a formal parameter name of the message 
or the identifier, sourceJask. The pragma 
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refers only to that subset of events for the 
specified message, in which the named 
parameter (or the source_task) equals the 
value of the associated expression, exp. If 
no value is specified for a formal parame¬ 
ter, then all values match. Message-re- 
cording events include not only tasking 
messages but also memory and device allo¬ 
cation and deallocation, shared-variable 
copy-in and copy-out, input/output wait¬ 
ing, and delay. 

Scheduling within a processor is treated 
as a single event type with the message 
name schedule: 

pragma event(schedule(task_list), on_off); 

The parameter association list of the prag¬ 
ma may be used to limit the effects of the 
pragma to the tasks listed. Both schedul¬ 
ing and unscheduling of a task are re¬ 
corded when its scheduling event is on. 

Correlating interprocessor events. The 
event-recording scheme assumes that each 
processor has its own clock. There is no 
guarantee that clocks in different proces¬ 
sors are synchronized or even that they run 
at the same rate. An additional mechanism 
is required to correlate independently re¬ 
ported interprocessor events. This is a 
special case of the general problem of cor¬ 
relating interprocessor events in distrib¬ 
uted systems with asynchronous clocks. 

In the DARP design, the general syn¬ 
chronization problem is solved by a con¬ 
ventional, sequence-numbering, commu¬ 
nication protocol scheme. For each pair of 
processors that have ever communicated, 
there is a counter in the sending processor. 
Before any message is sent, the counter in 
the sending processor is incremented and 
the value attached to the message. The re¬ 
ceiving processor keeps a record of the 
message numbers received from each send¬ 
ing processor. Arriving message numbers 
are compared with expected numbers to 
detect lost or out-of-sequence messages. 

These message numbers also provide a 
means to synchronize and correlate the 
times recorded for interprocessor events. 
Whenever an interprocessor event is re¬ 
corded in any processor, DARP also re¬ 
cords an interprocessor communication 
event consisting of the source and destina¬ 
tion processor, the communications se¬ 
quence number, and the local time. If the 
same event is recorded in the other proces¬ 
sor, the combined records show the unique 
sequence number and the corresponding 
local times within both processors. 


Future directions 

DARP is experimental and ignores 
many important issues. Nevertheless, it 
provides a variety of instrumental control 
and error-reporting mechanisms, which 
should allow others to investigate distrib¬ 
uted systems with greater ease. The system 
should provide a sound and efficient sub¬ 
strate for demonstrating distributed appli¬ 
cations on loosely coupled networks with 
large numbers of processors. 

The development of the distributed-tar¬ 
get operating system as an Ada run-time 
package has had several advantages. It 
provided a well-defined, high-level frame¬ 
work for tasking and exception handling, 
thus limiting the scope of possible designs 
and allowing us to concentrate on an effi¬ 
cient implementation of the Ada model. 
For the application developer or the dis¬ 
tributed-processing researcher, it means 
that development and experimentation 
can be done in the context of a modern, 
high-level language, designed specifically 
for large, multitasking, real-time applica¬ 
tions. Ada provides a common syntactic 
and semantic framework for interpreting 
experimental results. 

Retargetability. The DARP system, as 
currently defined, is not retargetable but 
should be relatively easy to port to other 
distributed targets. With the exception of 
the low-level functions of the input/out¬ 
put driver, interprocessor communica¬ 
tions, and task synchronization, the de¬ 
sign is independent of the BBN Butterfly 
and depends only on the general charac¬ 
teristics of loosely coupled systems. 

Operating system retargetability .de¬ 
pends on a target-independent design and 
on implementation in a machine-indepen¬ 
dent, high-level language, such as Ada. It 
is possible to automate the retargeting of 
DARP by replacing the code generator on 
the host machine of the Ada compiler. 
Ada encourages machine-independent de¬ 
sign by providing high-level features for 
tasking, error handling, representation 
specification, and real-time control, elimi¬ 
nating the traditional need for assembly 
language in such applications. Ada also 
provides a conditional compilation facility 
that can be used in conjunction with the 
package called System, a formal descrip¬ 
tion of the target machine configuration, 
to adapt applications to other configu¬ 


rations by recompilation. When Ada task¬ 
ing, exception, and real-time features are 
used in applications, Ada does not provide 
explicit operating system calls, instead 
requiring the compiler to implicitly 
generate calls on the appropriate functions 
of the target operating system; thus, Ada 
programs also are operating-system in¬ 
dependent. 

Ada greatly simplifies retargeting appli¬ 
cations at the expense of compiler com¬ 
plexity; Ada’s operating-system indepen¬ 
dence raises DARP to the status of any 
other application program by transferring 
many machine dependencies from the ap¬ 
plication program to the compiler. In the 
context of several applications for multiple- 
target environments, this transfer reduces 
effort to implement n applications on 
m machines from O(nxm) to 0(n+m). 


W e expect the Distributed Ada 
Run-time Package to facilitate 
our own and others’ distributed- 
system research, and we intend to exploit 
our experience with DARP to build Ada 
systems for commercial and industrial ap¬ 
plications. □ 
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A Parallel Inference 
Machine 


Hidehiko Tanaka, University of Tokyo 


Logic programming 
should be adaptable 
to parallel processing. 
The architectural 
design of the parallel 
inference machine 
called PIE employs it. 


S triking progress in computer tech¬ 
nology has given us single-chip com¬ 
puters whose processing power far 
exceeds that of the first-generation com¬ 
puters. We also have various high-level 
languages, operating systems, and data¬ 
base systems. As a result, we can now write 
programs for almost any kind of applica¬ 
tion, provided that we can explicitly 
describe their algorithms. This means that 
computers can replace people in many 
areas because of their high-speed process¬ 
ing and large memory capability. How¬ 
ever, there remain many application fields 
with hard-to-solve problems. One such is 
the knowledge-information processing 
field, where fifth-generation computer 
systems are expected to play an important 
role. 

A machine to cope with knowledge- 
information processing should support 
extensive storage of data and high-speed 
inference using the data. Up to now, in¬ 
ference processing has involved imple¬ 
menting functional languages and logic¬ 
programming languages, such as Lisp and 
Prolog, on conventional sequential com¬ 
puters. However, the need for processing 
power of new applications in knowledge- 
information processing may exceed the 
capabilities of conventional computers. 

The architecture of the parallel infer¬ 
ence machine makes it a possible candi¬ 
date for coping with such processing 
requirements. Computer architectures 
proposed for parallel inference ma¬ 
chines 1 include the data-flow machine 2 ’ 3 
and the high-level language machine 4 ’ 5 ’ 6 
for parallel inference. The machine ar¬ 


chitecture I discuss in this article is for a 
high-level language machine for parallel 
logic programming. 

Inference processing 

Prolog is a typical logic programming 
language based on first-order predicate 
logic. Each statement, called a clause, 
takes the form 

PO if PI and P2 and — Pn. 
where Pi is a predicate with some argu¬ 
ments and n >0. (For ease of understand¬ 
ing, I use a simple nonstandard notation.) 
For example, a program that represents 
the family relations of parent and grand¬ 
parent is expressed as 
grandparent(X.Y) if parent(X,Z) AND 


parent (Z,Y). (1) 

parent(j ohn, j ack). (2) 

parent(j ohn, mary). (3) 

parent(ann, mary). (4) 

parent(mary, paul). (5) 

parent(mary, peter). (6) 

parent(bill, peter). (7) 


where words beginning with capital let¬ 
ters represent variables and lowercase 
words atoms. 

When the question “Who is the grand¬ 
parent of peter?” (grandparent (X,peter)?) 
arises, inference operations execute as fol¬ 
lows: Using Rule (1), the original question 
is converted to a new question of the form 

parent(X,Z) AND parent (Z, peter)? (8) 
where X and Z are variables to be 
determined. 
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To solve this new question, we have 
two alternatives: to solve the first part 
(parent (X,Z)) first, or to solve the second 
part (parent(Z, peter)) first. Because this 
decision affects the efficiency of search 
operations, we need some algorithms to 
select the best way to proceed. In this ex¬ 
ample, it is more efficient to evaluate the 
second part before the first. Accordingly, 
conditions that fulfill the second part of 
Rule (8) are searched for in the program. 
Two values are found for variable Z from 
Rules (6) and (7)—Z = mary and Z = bill. 
For each value, the first condition of Rule 
(8) is tested next and two solutions— 
(X=john, Z = mary) and (X = ann, Z = 
mary)—are found. 

When we call the question at each step a 
goal, the operation steps of Prolog can be 
considered goal-reduction steps. In con¬ 
ventional sequential Prolog, the search 
and test operations (called unifications) 
are executed one by one, but parallel 
search and test operations can be imple¬ 
mented through parallel machine architec¬ 
ture to obtain a high-speed machine. 

Parallelism. A few sources of parallel¬ 
ism can be distinguished for parallel execu¬ 
tion of Prolog as follows: 

(1) AND parallelism; 

(2) OR parallelism; and 

(3) argument parallelism. 

When the goal is expressed as “Q1 AND 
Q2—Qm?”, AND parallelism can be used 
to search for conditions for all literals 
(Qi : /'= 1,2,—,/m) in parallel. Generally 
speaking, because arguments in a goal 
may be related to each other, a consistency 


check may be needed following the paral¬ 
lel search of AND conditions to ensure 
that all references to the same variable 
have the same value. OR parallelism can 
be used to search and test all conditions for 
each literal Qi in parallel. The conditions 
found by OR parallelism are independent 
of each other. Therefore, the operations 
can be executed independently. Argument 
parallelism refers to the process of unify¬ 
ing several arguments of a literal in paral¬ 
lel. As arguments may be related to each 
other, a consistency check is needed in 
general. 

Figure 1 shows an example of measure¬ 
ment of OR parallelism for an eight- 
queens chess problem. The program finds 
all placement patterns for eight queens on 
an eight-by-eight chessboard. The hori¬ 
zontal axis is the number of inference steps 
and the vertical axis, the number of paral¬ 
lel executions at the step. Due to the multi¬ 
plication of OR parallelism, the maximum 
number of parallel goals amounts to about 
two thousand. 

Other operations. For practical pro¬ 
gramming language considerations, the 
Prolog functions stated above are not 
enough. Candidates for supplementary 
functions include the 

(1) NOT operation, 

(2) SET operation, and 

(3) GUARD operation. 

Although pure Prolog statements assert 
only that a clause is true, in some cases of 
rules and facts it can be more efficient to 
assert that the clause is false. NOT ex¬ 


Figure 1 . Number of parallel goals (eight 
queens). 


presses such rules and facts. The SET op¬ 
eration gathers values that fulfil some con¬ 
dition in a set. The GUARD operation 
selects a goal nondeterministically from 
among several OR goals. Goals not se¬ 
lected are discarded. 

Architectural points 

When designing a parallel machine ar¬ 
chitecture that can exploit large-scale par¬ 
allelism, we should consider several archi¬ 
tectural points. 

Parallelism to be supported. As stated 
before, at least three kinds of parallelism 
can speed up processing. Although we 
would like to use all three kinds, AND and 
argument parallelism are difficult to im¬ 
plement. However, we can achieve AND 
parallelism through pipeline processing of 
two literals connected by the AND rela¬ 
tion, as shown in Figure 2. In the figure, 
the goal is “QI AND Q2 ?” When the 
unify processing of literal QI finishes, the 
results are fed to literal Q2. When the 
number of results of QI is greater than 1, 
generation of the second result of QI can 
occur in parallel with the unification of Q2 
using the first result. Although conven¬ 
tional AND parallel operation needs a 
consistency check afterward, this pipeline 
operation does not and thus is efficient to 
implement. 

Goal-search algorithm. Because infer¬ 
ence processing corresponds to a search 
operation on a tree such as the one in Fig- 
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ure 2, the search strategy has an important 
effect on processing efficiency. Four issues 
are important regarding this algorithm. 
One issue is the tree-traverse strategy, such 
as depth-first and breadth-first. In sequen¬ 
tial processing, a tree traverse is done node 
by node, so that failure at one node causes 
backtracking to an alternative path. In 
parallel processing, many kinds of search 
strategies exist, mixing depth-first and 
breadth-first strategies. One such we call 
conclusion precedence. In this strategy, 
higher priority is given to a goal frame 
theoretically nearer to the conclusion (fail¬ 
ure or success), using as the parameter the 
depth number of the node where the literal 
is introduced to the goal frame. Although 
in our tentative simulations this strategy 
shows 4 comparatively good performance 
both in finding the first solution and in 
getting all solutions for the simulation pro¬ 
grams, we need to study this aspect more 
thoroughly. 

The second issue, the literal selection 
strategy, should be solved first in each goal 
frame. For this selection, we can use such 
parameters as the number of candidate 
clauses and the argument binding status of 
each literal. 4 

The third issue is the utilization of the 
programmer’s choice of search strategy, 
such as read-only annotation. Read-only 
annotation restricts the location of vari¬ 
able binding, thus affecting the search se¬ 
quence. 


The fourth issue is the elimination of re¬ 
computation that may occur many places 
in a tree. For this purpose we need a mech¬ 
anism that memorizes past experience. 

Processing model. A parallel-inference 
machine has a large storage area that holds 
many goals. I call the data structure of a 
goal a goal frame. Two typical schemes of 
goal frame data structures are shown in 
Figure 3. One, the perfect-copy scheme, 
allocates a separate memory area to each 
goal frame. The other, the data-sharing 
scheme, shares common parts of goal 
frames, identifying them by means of 
pointers. Although copying overhead is 
induced, the perfect-copy scheme lends it¬ 
self well to load-leveling mechanisms. On 
the other hand, the data-sharing scheme is 
efficient in memory and time consump¬ 
tion, although somewhat complicated to 
implement. In reality, a combination of 
both schemes may be best. Some part of a 
goal should be shared among many goals; 
the rest of it should be stored independent¬ 
ly. The key point is to find the proper com¬ 
bination. 

Machine organization. For each unifi¬ 
cation of a goal, a program composed of 
many rules and facts is searched to find a 
candidate clause that can be used to unify 
a literal of the goal. Because a parallel in¬ 
ference machine has many processors, 
many simultaneous accesses to program 


memory arise. To alleviate access conten¬ 
tion, the machine should be equipped with 
many separate memories (called definition 
memories) to store the same program. 
When program size grows, all programs 
cannot be stored in the high-speed defini¬ 
tion memory. Accordingly, in the future 
we should incorporate secondary storage 
to facilitate the cache concept, where only 
the necessary part of a program is copied 
to the definition memory. 

Connection networks of element mod¬ 
ules are also an important issue. To realize 
a parallel machine of more than 100 pro¬ 
cessor elements, we should consider 
clustering processor elements to take ad¬ 
vantage of processing locality. By divid¬ 
ing one cycle of operation into several 
stages, we can take pipeline control into 
account to achieve sufficiently high 
speed. One example of pipeline stages is 
shown in Figure 4. 

In general, there are several candidate 
clauses for one literal of a goal. In Figure 
4, the final three stages of unification for 
each candidate clause are independent of 
each other and can be processed in parallel. 

Machine control. A characteristic of 
parallel-inference processing is dynamic 
load generation and consumption. For 
any kind of parallel machine with this load 
characteristic, a dynamic load-control 
scheme is essential for utilizing machine 
resources effectively. Figure 5 shows a dis- 
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Figure 5. Distributed model of load control. 


tributed model of load control. Tasks are 
stored in memory modules. Each proces¬ 
sor fetches a task from a memory module, 
processes it, and generates a few tasks as 
the results. Load control can be done in 
two ways. One method involves fetching a 
task from a memory module with many 
tasks. The other method involves dis¬ 
patching newly generated tasks to lightly 
loaded memory modules. 

Only one of the two methods should be 
needed for most situations. One memory 
module can be local to a processor. Ac¬ 
cordingly, the following organization of¬ 
fers a good solution for load control: 

(1) Tasks are always fetched from the 
local memory module, and 

(2) Newly generated tasks are dis¬ 
patched depending on the load of each 
memory module. 

Because this scheme assumes monitoring 
of load balance among modules, we need 
to incorporate a measurement mechanism. 
However, the information from a search 
tree can be used for load control instead of 
dynamic monitoring. 

The other feature of machine control re¬ 
lates to the implementation of supplemen¬ 
tary functions such as NOT, SET, and 
GUARD operations. Although OR-re- 
lated goals are independent of each other, 
goals become interrelated when these 
functions are introduced. For example, 
Figure 6 shows the implementation of 
NOT operations. When “NOT Q ?” is exe¬ 



cuted as a goal and there exist two defini¬ 
tion clauses for Q, the unification generates 
two AND nodes (NOT R AND NOT S). 
This contrasts with the generation of two 
OR nodes when the goal is simply “Q ?” 

The same situation occurs when the 
other supplementary functions are used. 
We need some global control mechanism 
to implement these functions and to inter¬ 
relate the processing of goals. 

Proposed architecture- 
PIE 

Based upon the consideration stated 
above, we 4,7 have proposed a parallel in¬ 
ference machine called PIE, for Parallel 
Inference Engine. Figure 7 shows the 
global organization of PIE. Because the 
PIE architecture continues to evolve, this 


Figure 6. The implementation of NOT 
operation. 


figure shows the second version of the ar¬ 
chitecture. 

This machine has a two-level organiza¬ 
tion. The Level-1 system is a cluster of in¬ 
ference units, or IUs. The second level is a 
subset of the Level-1 systems. PIE as¬ 
sumes 64 Level-1 systems. It also assumes 
the number of inference units in a Level-1 
system to be 16, so the total number of in¬ 
ference units is 1024. The system manager, 
or SMR, of PIE manages global activity 
through intercluster control of Level-1 
systems. 

Figure 8 shows the detailed organization 
of a Level-1 system, including seven mod¬ 
ules and three networks: 

• memory module, or MM; 

• unify processor, or UP; 

• definition memory, or DM; 

• lazy-fetch buffer, or LFB; 

• activity controller, or AC; 
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• structure memory, or SM; 

• activity manager, or AM; 

• distribution network, or DN; 

• lazy-fetch network, or LFN; and 

• command network, or CN. 

IU #15 is special in that it acts as an in¬ 
terface module to a Level-2 network. It 
also includes an SM that stores structure 
data. This SM is shared by all IUs in the 
Level-1 system. The AM is a centralized 
controller of the Level-1 system. 

Memory module and unify processor. 

The MM stores goal frames. All MMs in a 
Level-1 system make up a goal pool. The 
UP fetches a goal frame from its local 
MM, unifies the frame, and stores the re¬ 
sulting new goal frames in the goal pool. 
For this store operation, the memory 
module in which the new goad frame is 
stored is determined by a load-dispatching 
algorithm. That is, if the number of local 
goal frames stored is greater than a thres¬ 
hold, the goal frame is output to DN and 
transmitted to an external MM. The desti¬ 
nation MM is selected randomly so that 
the number of goal frames is less than a 
threshold. 


This strategy is called empty self. Alter¬ 
native strategies are first self and random. 
In first-self strategy, the most recently gen¬ 
erated goal frame is always stored in the 
local MM and the rest are transmitted ran¬ 
domly to other, external MMs. Random 
strategy distributes all new goal frames 
randomly to all MMs. 

Figure 9 shows a simulation result of the 
load-leveling strategies. The vertical axis 
designates the number of working UPs; 
the number of physical UPs is assumed to 
be 64. As can be seen from this figure, 
empty-self strategy is best in the sense that 
the load is dispatched faster to idle UPs 
and that processing ends first. 

Figure 10 shows a simulation result of 
the relative execution speed of PIE. The 
horizontal axis designates the number of 
UPs. The vertical axis designates the rela¬ 
tive speed compared to a single UP ma¬ 
chine. The application programs are the 
eight-queens and six-queens chess pro¬ 
grams, and a cryptoarithmetic program 
called LL2P. In this example, the parallel 
speed gain for the eight-queens program is 
about 170 when the number of UPs is 256. 

In these sample programs, the process¬ 
ing time of one inference step is about 300 


micro steps for the eight-queens program 
and 900 micro steps for the cryptoarithme¬ 
tic program, assuming microprogram- 
controlled hardware. Accordingly, the 
processing time is about 60 and 180/is, 
respectively, with a clock period of 200ns, 
so that the granularity of this machine is 
rather coarse. 

When a new goal frame is generated, the 
frame size grows linearly with respect to 
the unification steps if the conventional 
unification algorithm is used. However, 
Moto-Oka et al. 4 have shown by simula¬ 
tion that the size can be kept roughly con¬ 
stant if a size-reduction process is applied 
to new goal frames. This process eliminates 
unneeded intermediate variables. Although 
a rather costly operation, it improves the 
effective parallelism of the copy scheme. 

Definition memory and structure mem¬ 
ory. DM stores all definition clauses of the 
program. All DMs have the same copy of 
the program. 

DM searches candidate definition clauses 
that may match the head predicate pre¬ 
sented by UP. Clauses found are fed to the 
UP one by one. Following this, the UP 
performs unification one by one. 
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Figure 9. Comparison of load-leveling strategies. Figure 10. Relative execution speed of PIE. 



PIE adopts a data-sharing scheme for 
goal frames. The shared part is stored in 
SM and the nonshared part in MM. When 
a goal-fetch operation is done by a UP, the 
nonshared part is transferred from MM to 
the UP, whereas the shared part is not 
transferred. Access to the shared part oc¬ 
curs on a demand basis. That is, if access 
becomes necessary within unification, it is 
done. This access is called lazy fetch. The 
data accessed by one lazy-fetch operation 
is not the whole volume of structure data, 
but a few words of fixed length. LFB be¬ 
haves as a cache to decrease SM access. 

In PIE, not all of the shared data is 
stored in SM. For simple implementation, 
data in SM are restricted to immutable 
data such as structures made of ground in¬ 
stances only. These data are not changed 
once created. When it becomes clear that 
the data will not be accessed any more in 
future, the data are deleted and the memory 
area is garbage-collected into a free-cell 
list. Due to the immutability of content, 
the garbage-collection algorithm becomes 
very simple. 

The number of IUs in a Level-1 system 
is limited by the traffic of SM access. From 
preliminary simulation results, 4 it is esti¬ 
mated to be less than 20. The effect of pro¬ 
viding SM is to reduce the goal frame size 
into less than a half, although its precise 
value depends on each application. 

Activity controller and activity manager. 

As stated before, goal frames should be in¬ 


terrelated so as to support some supple¬ 
mentary functions. For this purpose, all 
goal frames are managed by a tree struc¬ 
ture stored in ACs, as shown in Figure 11. 
This tree is called an inference tree. Each 
AC maintains the information of nodes 
for which goal frames are stored in the 
local MM. Nodes are also connected to re¬ 
mote nodes in the other modules, using 


Figure 11. Management of 
goal frames. 

pointers. When a new goal frame is gener¬ 
ated, a new node area is reserved and tree 
connections are created. When some goal 
succeeds or fails, the corresponding node 
transmits the result to its parent node and 
deletes itself. 

At all times the AC monitors the local 
load in terms of the number of goal frames 
and periodically transmits the summing- 
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up report to AM. After receiving load in¬ 
formation from all ACs, the AM fixes a 
threshold value for load control and broad¬ 
casts this value to all ACs. The AC sets up 
the local IU using the threshold value for 
the empty-self algorithm. 

AM serves as an interface module to a 
Level-2 network as well. In the Level-2 
network, all AMs in PIE behave for SMR 
just like ACs in a Level-1 system. The 
SMR controls the load balance among 
Level-1 systems by fixing another theshold 
value for all AMs. When the total load of a 
Level-1 system exceeds the threshold value, 
the AM dispatches part of the load to 
another Level-1 system. At this time, the 
AM concatenates the shared part of a goal 
frame to the nonshared part and transmits 
the resulting goal frame in complete form 
to the other Level-1 system. Accordingly, 
the structure data stored in SM is not 
shared beyond a Level-1 system. 

Concluding points 

One of the key points in achieving a 
highly parallel machine is the selection of 
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granularity of processing tasks. This gran¬ 
ularity should be determined based on the 
balance between processing time of each 
task and other overhead time, such as data 
transfer delay and control delay. In the 
case of inference processing, this granular¬ 
ity can be set comparatively large, as a uni¬ 
fication operation usually takes hundreds 
of conventional machine code cycles. 

The second important point is the bal¬ 
ance between copying and sharing of data. 
Although copying makes machine organi¬ 
zation simple, sharing makes operation 
and memory utilization efficient. 

The third important point is control 
overhead. For a highly parallel machine, 
the central facility should be invoked as lit¬ 
tle as possible to avoid becoming a bottle¬ 
neck in the system. Global control tends to 
become such a bottleneck. We need a 
smart mechanism to select between dis¬ 
tributed and centralized control and thus 
give us satisfactory results. 

I have presented here a parallel machine 
architecture, PIE, which I expect to be 
the base for highly parallel inference 
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machines. On a small sample of problems, 
experimenters have obtained speedups 
ranging from 20 to 170 times the single¬ 
processor system speed for a system with 
256 processors. The experiments show 
that the architecture has the potential to 
attain very high performance from parallel 
operation, but that speedup can be fairly 
low as well. Additional research will deter¬ 
mine what speedup we can expect for par¬ 
ticular classes of problems. We also need 
to develop techniques for achieving very 
high speedup on those classes of problems 
that currently exhibit poor speedup. Fur¬ 
ther study should focus on more precise 
evaluation, analysis, 8 and building an 
experimental system. 

Finally, we should incorporate several 
improvements in the machine organiza¬ 
tion, such as pipeline control, associative 
search of clauses, garbage collection 
hardware, and support of secondary 
memory. □ 
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Agora-An Experiment in 
Multimedia Message 
Systems 


Najah Naffah and Ahmed Karmouch, Bull Transac 


The Agora multimedia 
message system was 
designed as part of 
the Kayak project 
employing a multisite 
architecture for the 
distributed, integrated 
electronic office. 


W e consider a distributed message 
system that allows exchange of 
compound documents among 
workstations to be the foundation of in¬ 
tegrated office systems in the future. 
Although not widely used in corporations 
today, experiments like the one we de¬ 
scribe here have shown the feasibility of 
these concepts. In particular, they have 
highlighted some essentials for a technical¬ 
ly successful electronic office system: 

• multimedia workstations with good 
interface features, 

• reliable message transfer, 

• a flexible naming scheme, and 
• a multisite, distributed architecture. 
We here describe the Agora project, 
conducted within the context of a larger 
project called Kayak, 1 and its architec¬ 
ture. Agora’s functional model was de¬ 
fined in parallel with the IFIP model. 2 
Kayak’s goal was to build a complete, inte¬ 
grated electronic office. 


The Kayak project 

When the decision was made in France 
in 1979 to launch a pilot project of office 
systems, word processors had just begun 
to penetrate the office automation mar- 
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ket. On the other hand, there were few 
electronic-mail systems except in univer¬ 
sities, research laboratories, and a few 
private companies. Arpanet mail, 3 built 
into the host systems connected to Arpa¬ 
net, serves as a good example of a research 
mail system. Local networks were in the 
embryonic stage. Only Xerox PARC had a 
prototype of bitmapped workstations 
connected through the Ethernet local net¬ 
work to mail, file, and printing servers. 4 
In the pilot project, called Kayak, 1 we 
wanted to explore in depth the concept of 
an integrated office system. 

We investigated office integration at 
different levels: workstation, network, 
and application. The workstation goal was 
to build a personal machine supporting the 
functions necessary to acquire and present 
the kinds of media used by office workers 
in their daily tasks—voice, plus written 
documents containing manuscript, typed 
text, drawings, pictures, and graphics. A 
friendly interface criteria led to a voice 
command and signalling system, a large 
bitmap screen, a pointing device, and a 
standard keyboard. 

The workstation, called Buroviseur, 5 
was assembled from the components 
shown in Figure 1. It has a multiboard ar¬ 
chitecture based on the Intel Multibus. All 
boards have the standard Intel SBC for- 
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mat. Some boards, like the CPU (8086), 
memory (512K bytes), and disk controller, 
have been adopted off-the-shelf. Others, 
like the bitmap-mouse-keyboard driver, a 
hundred-word voice recognition system, 
text-to-speech synthesis, and voice codec 
boards, were designed internally. 

The software running in the worksta¬ 
tions of Kayak contains the necessary 
drivers for all these devices, plus a set of 
application programs for document man¬ 
agement. Two important packages in the 
message application are the multiwindow 
package, called Vitrail, 6 and the com¬ 
pound-document editor/formatter, called 
Plume. 7 

Vitrail is a standard windowing package 
with a high-level interface to the applica¬ 
tion program developers, who interact 
with devices by manipulating primitives 
such as open window, display object, 
create menu, read input, and the like. The 
multiwindow package is built on top of a 
toolkit that deals with 

(1) display of all objects, including mul¬ 
tifont characters, graphical objects, and 
facsimile boxes; 

(2) object manipulation, such as copy, 
move, reduce, and zoom; and 

(3) the conversion of data, such as text- 
to-speech and word recognition. 

The editor, Plume, is a WYSIWYG 
(what you see is what you get) editor that 
deals with structured documents contain¬ 
ing entities of different levels, including 
chapters, sections, paragraphs, characters 
of various fonts, and alphabets. 

Vitrail has enormously facilitated the 
implementation of the user agent (ex¬ 
ploitation features) in the Buroviseur. On 
the other hand, Plume has served as the 
basis of interaction in Agora, the multi- 
media message system. 

A local network based on the CSMA- 
CD access scheme interconnects worksta¬ 
tions. A lM-byte-per-second baseband 
local-area network, or LAN, called Dan¬ 
ube, it can cover two kilometers and 
connect 255 nodes. Different Danube net¬ 
works were connected with X.25 gate¬ 
ways. 8 This architecture is the infrastruc¬ 
ture upon which the distributed message 
system was installed with distributed name 
servers and messaging servers. In a typical 
site, lM-byte-per-second provides enough 
bandwidth to exchange multimedia mes¬ 
sages among workstations. Real-time 
voice messages are exchanged through a 


telephone network driven by specific ports 
in the Buroviseur. No voice packets for 
real-time dialogue were adopted or mixed 
with non-real-time traffic. This decision 
was made because the potentially heavy 
load generated by real-time traffic would 
create instability in the CSMA-CD-based 
Danube network. However, pseudo-real¬ 
time information exchange among users 
takes place by means of workstations 
equipped with speech synthesizers. Text 
entered on one workstation can im¬ 
mediately be sent to another workstation 
and converted to voice. 

Danube provides communication sup¬ 
port corresponding to the first five layers 
of the ISO model for open systems inter¬ 
connection. The NBS protocol 9 has been 
used above the session layer to exchange 
messages, while an SGML-like coding 10 
has been adopted for the document 
structure. 

Integration at the application level is as 
important for the user as the integration at 
the workstation level or the network level. 


Figure 1. Buroviseur 
components. 

It implies coexistence and information ex¬ 
change among various applications. On a 
practical level, the user can switch between 
applications without stopping one to run 
another. He can also ask to take one docu¬ 
ment or piece of a document from one ap¬ 
plication and use it in another. In our im¬ 
plementation, this process was facilitated 
by the adoption of the same document 
representation standard and common ses¬ 
sion services in the workstations and 
servers. 


The Agora architecture 

The Agora system is designed according 
to a distributed and open architecture. 
From the conceptual point of view, Agora 
is based on a functional model similar to 
the IFIP model 2 and consists of different 
entities that work together to provide com¬ 
munication services. 
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Architectural model. A schematic 
description of the architecture appears in 
Figure 2. The components are as follows. 

Message transfer system. The MTS con¬ 
sists of several message processors called 
message processing ends, or MPEs, that 
provide the functions needed to route 
messages from the originator user agent, 
or UA, to the recipient UA. The MPEs to 
which the originator and recipient UAs are 
attached are called originator and recip¬ 
ient MPEs, respectively. During the 
routing of a message, MPEs other than 
these two may be involved. If so, they are 
called intermediate MPEs. 

User agent. The UA, a set of application 
processes, provides several functions: 
functions necessary to interact with the 
MTS and retrieve messages, and functions 
necessary to interact with the user to 
prepare and present outgoing and incom¬ 
ing messages. 

Name server. The NS, a distributed 
database of names, manages the Agora 
users (humans, processes, and roles). The 
functions provided are mainly those 
necessary for manipulating names (creat¬ 
ing, changing, and removing names) and 
names-to-address mapping. The NS can 
be reached from an entity called the client, 
a program that offers a set of primitives 
that allow its users to obtain all the func¬ 
tions provided by the name server. The 
client may be located in both UAs and the 
MTS. 

Protocols. The interactions between the 
entities that appear in the architecture are 
managed and ruled by appropriate proto¬ 
cols. They are identified as submission and 


retrieval protocols for the interactions be¬ 
tween UAs and the MTS, as intermediate 
or relay protocol for the interaction be¬ 
tween two MPEs, and as the client name 
server protocol for the interaction between 
the client and the name server to which it is 
attached. Interactions between name 
servers are managed by intername servers 
protocol. 

The similarity between the Agora ar¬ 
chitectural model and the CCITT model 
for message handling facilities 11 is 
natural. Both systems were based on the 
IFIP model. However, the implementa¬ 
tion of Agora started before the CCITT 
model was defined. 

Physical mapping. The Agora model is 
implemented with the following com¬ 
ponents: 

• the access point, built in the Burovi- 
seur, which offers the user agent 
facilities; 

• the message server, which contains 
one MPE and a set of mailboxes; and 

• the name server, which manages par¬ 
titions of the subscribers’ names. 

The definition and role of these com¬ 
ponents can be explained by a description 
of operations executed from the time 
when a user has a message to communicate 
to the time when his message is perceived 
by another user. The two types of users are 
the originator, or the information creator, 
and the recipient, or the destination of the 
information. 

The originator prepares his message 
with the Plume editor acting as the UA 
located in the Buroviseur. The UA pro¬ 
duces a standard message for further 
transmission. The message is structured 
into various fields with equivalents to the 


envelope and content of standard mail. 
The former contains information neces¬ 
sary for routing the message. The latter 
contains information that the originator 
wants to communicate to the recipient. It 
contains a header and the body. The body 
may consist of different parts, each with 
various types of information (graphics, 
text, voice, and image). 

The UA submits the message to the orig¬ 
inator MPE. The MPE undertakes the 
analysis of all the envelope elements and 
may refuse the submitted message. During 
the envelope checking, the originator 
MPE may send queries to other compo¬ 
nents of the system (the name server) to 
obtain more information about the origi¬ 
nator rights. Once an MPE has accepted 
the message for forwarding to the destina¬ 
tion MPE, it starts a new phase of localiza¬ 
tion of the resources containing the 
mailbox. 

To perform this function, the MPE asks 
the name server to provide the mapping 
between the recipient’s name and the cor¬ 
responding mailbox address. After the 
localization phase, the MPE establishes a 
route (according to its internal table) to the 
MPE that handles access to the mailboxes 
in the mail server. 

In establishing the route, other MPEs 
may be involved. They act as intermediate 
MPEs. Private and public transmission 
media may be used to connect two MPEs 
on both ends. Once a route is established, 
the transfer of the message is performed 
and stored in the recipient mailbox located 
in the message server managed by the re¬ 
cipient MPE. The recipient can retrieve 
messages from his mailbox through his 
UA. 

Name server 

The name server represents the entity 
responsible for the management and ad¬ 
ministration of names. The management 
functions deal more specifically with 
names and addresses such as mapping, 
lookup, or list members of a distribution 
list, while the administration functions 
deal with attributes of mailboxes (such as 
right to write and delegate access) and the 
updating algorithm when a name or an ad¬ 
dress is to be created, changed, or re¬ 
moved. 

Structure of names. Names are struc¬ 
tured in a hierarchical manner. The 
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method used consists of breaking down 
the name domain into groups, each man¬ 
aging its own space of internal names. 

A group is an attribute that can take dif¬ 
ferent and unique values. Each value may 
represent an authority or an administra¬ 
tion to which all local users are connected. 
An internal name is an attribute that may 
have different and unique values. Each of 
these values represents a user name be¬ 
longing to a given group to which it is at¬ 
tached. Thus, the name of an Agora user 
takes the form 

<user name>=<group name> 
< internal name> 

The relation that exists between these two 
attributes is a hierarchical relation. The 
main advantages of this representation are 
reduction of ambiguity in names, and flex¬ 
ibility and adaptability for decentralized 
schemes and the naming authority. This 
naming scheme is satisfactory within an 
organization, but it should be extended to 
cover more attributes in an international 
environment. 

Types of names. The name server in 
Agora defines and manages different 
types of names, including 

• individual, an ordinary subscriber 
known to the system by his or her in¬ 
dividual name (In addition to the mailbox 
address associated with the name, a pass¬ 
word and a mailbox access key are also at¬ 
tached to the name for protection of the 
mailbox and control of information.); 

• alias, considered another name of the 
individual to whom it is linked; 

• distribution list, a list of predefined 
subscriber names (members of the list); 
and 

• teleconference list, with a definition 
similar to that for the distribution list, but 
with a wider range of facilities. A telecon¬ 
ferencing list has an organizer, who is the 
creator of the list. A teleconference may be 
public or private. A public teleconference 
may be joined by any subscriber at any 
time. A private teleconference is restricted 
to subscribers authorized to join by the 
organizer. 


Management of names. To keep infor¬ 
mation about group names continuously 
available, the database of group names is 
replicated in each name server. For the 
same reason, partitions of names may also 


be replicated. Hence, all the name servers 
have the same copy of names on different 
sites. 

Because of the nature of message system 
applications, in which delays are counted 
in terms of minutes, hours, and even days, 
we can tolerate temporary inconsistencies 
that may occur during conflicting update 
operations of the name database without 
any damage. Accordingly, in Agora an 
optimistic updating algorithm is used 
based on a time-stamping mechanism 
summarized as follows: 

The most critical update operations are 
create-name and delete-name queries. 
They can be initiated by any administrator 
from any site by interrogating the local 
name server. When a create-name query is 
received by a given name server from an 
administrator, a time stamp is attached (at 
the name server level) to the query, which 
is processed locally to see if the new name 
to create is already registered. 

If this is the case, the create-name query 
is rejected. If not, the name is added with 
its time stamp to the name server and the 
update operation is broadcast to all other 
name servers. 

Upon receipt of the update operation, 
each of the other name servers performs 
the query as follows: If the name to create 
does not exist in that name server, the 
name is added to it with its time stamp. 
Otherwise, the time stamps are compared. 
The name that has the most recent time 
stamp is ignored and the other name is 
kept in the name server with its time 
stamp. 

For the delete-name query, the process 
differs. It is performed locally by the initi¬ 
ator name server, which compares the 
query time stamp and the time stamp of 
the already-registered name that must be 
deleted. The name is deleted if the query 
time stamp is more recent than the one 
associated with the registered name. 
Otherwise, the query is ignored. When the 
delete-name query is performed locally by 
the initiating name server, it is broadcast 
to all other name servers, which process 
the query in the same way as in the initiat¬ 
ing name server. 

The delete-name operation is per¬ 
formed in two steps: 

(1) The name is marked “name in dele¬ 
tion progress” and must not be recreated 
until it is removed from the name server. 


We believe that a 
simple optimistic 
algorithm takes 
less time than 
other algorithms 
and provides a 
satisfactory 
solution here. 


(2) The name is removed from the data¬ 
base of valid names. 

This second step can be performed after 
time, even in the order of weeks, because 
we want to ensure that the name is deleted 
from all name servers before it is re¬ 
created. 

Notice that each initiating name server 
performs an update operation before 
broadcasting it to all other name servers. 
Theoretically, the update operations 
should be received by the other name serv¬ 
ers in the same time ordering as they were 
sent. However, this cannot be guaranteed 
because of the transmission delays and the 
computers’ variable load. The result: in¬ 
consistency may occur for a period of 
time. Furthermore, the time-stamp 
mechanism used here does not guarantee 
that the administrator who initiated the 
update operation will win, because of the 
desynchronization of clocks between dif¬ 
ferent name servers. 

However, from our experience we be¬ 
lieve that a simple optimistic algorithm, 
like the one we implemented, takes less 
time than other algorithms and provides a 
satisfactory solution in the context of a 
decentralized name server dedicated to a 
store-and-forward message communica¬ 
tion system. 


Message server 

The message server is the tool that 
allows the user to receive messages from 
other subscribers and to retrieve messages 
from his mailbox. We might say that a 
message server is a collection of mail¬ 
boxes. 

We must emphasize that grouping of 
mailboxes in a message server does not 
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Figure 3. Agora implementation configuration. 


reflect the naming strategy adopted in a 
name server. Within a message server, 
subscribers can belong to different 
groups. Likewise, all subscribers belong¬ 
ing to a given group can have their mail¬ 
boxes in different message servers. The 
distribution depends on economic con¬ 
siderations, as well as professional criteria 
allowing a subscriber to have his mailbox 
(a primary mailbox if there is more than 
one) as close as possible to his current ac¬ 
cess point. 

Server implementation. The first im¬ 
plementation of the message servers and 
name servers in Agora occurred in the 
mainframe Honeywell-Bull DPS8, located 
at INRIA- Rocquencourt (see Figure 3). 
The operating system was Multics. Three 
modules were installed: the name server, 
the message server, and a UA activated 
when access takes place with TTY ter¬ 
minals through Transpac (the national 
packet switched network in France). Dan¬ 
ube was connected to Transpac through a 
special X.25 gateway. All Buroviseurs 
connected to Danube have their own UAs 
that can talk directly to the name and 
message servers in the mainframe without 
going through the TTY UA. 


To manage storage and retrieval of 
messages, we used the Multics relational 
data store (MRDS), a relational database 
management system (DBMS). However, a 
DBMS does not suit large volumes of data, 
such as those contained in the bodies of 
messages. Hence, we restricted the use of 
MRDS to the fields of the header. The 


message body was managed by FMS, the 
Multics file management system. 

MRDS itself remained hidden from 
users and served only as an implementa¬ 
tion tool. User commands were mapped 
into MRDS queries by a special program. 

Use of MRDS as an implementation 
tool benefited programming productivity. 
However, it is not mandatory to use a rela¬ 
tional DBMS in a CBMS to enhance the 
quality of service. In fact, it increases the 
volume of code resident at run time and 
necessitates a large memory. For this 
reason, we decided to build another ver¬ 
sion of the name and message servers on 
top of a simple access method that uses 
FMS. 

The implementation described was 
ported to an 8086-based microserver with 
70M bytes of disk space. The volume of 
code in the mainframe measures approx¬ 
imately 22,000 lines of PL1. 

The user agent 

As in other mail systems, we faced the 
problem of terminals with different 
degrees of intelligence—teletype-like ter¬ 
minals, sophisticated workstations such as 
the Buroviseur, and telex terminals. The 
challenge: to provide a consistent interface 
for the various users independently of the 
type of terminal. 

The user agent architecture consists of 
three modules: the dialog manager, the 
message editor, and the protocol handler. 
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Dialog manager. Agora provides the 
user with the services of administration, 
teleconferencing, and mail. The functions 
included in these services are represented 
as a tree, which also gives the structure of 
the command language. 

The administration tree has five 
branches representing five sets of com¬ 
mands: group, subscriber, alias, distribu¬ 
tion list, and conference. In the group set, 
the user can list all groups managed by 
Agora, or search for a specific group. The 
subscriber set includes functions to pre¬ 
sent and modify the user’s various param¬ 
eters. The alias set allows for manipulation 
of additional names assigned to the user. 
The distribution list allows the user to 
create or delete distribution lists, or to 
manipulate a specific list. The conference 
set deals with the creation and manipula¬ 
tion of teleconferences and their 
parameters. 

The mail tree contains the traditional 
commands of creating, filing, retrieving, 
and redistributing messages. 

The teleconference tree allows the user 
to enter and participate in a teleconference 
by sending different types of messages (in¬ 


tervention, question, note, vote, and so 
forth) and retrieving or archiving informa¬ 
tion exchanged during a teleconference. 
Figure 4 illustrates the teleconference tree. 

The syntax of every command follows 
exactly the tree structure. The materializa¬ 
tion of the tree varies according to the 
available resources and intelligence of the 
terminal. For the Buroviseur, where a 
multiwindow package exists, dialog takes 
place through selection of commands dis¬ 
played in a hierarchy of menus that exactly 
reflects the tree structure. Parameters are 
entered directly into predefined forms 
displayed on the screen (see Figure 5). 

In the case of teletype, a query-response 
dialog replaces this interface. All queries 
and answers are displayed or entered in 
line mode. 

Obviously, the first type of dialog is 
more practical because of the direct selec¬ 
tion of commands with the mouse, the im¬ 
mediate feedback, and the simultaneous 
views on the screen of the steps of the in¬ 
teraction. 

Although the difference between physi¬ 
cal representation of both interfaces is im¬ 
portant, we have succeeded in providing 


the same logical interface, and thus the 
same service, to both categories of users. 

The multimedia editor. The multimedia 
editor used to prepare compound docu¬ 
ments on the Buroviseur is fully interactive 
(what you see is what you get). Is is based 
on a system of menus and icons inside the 
menus representing the commands or the 
objects. At initiation time the system 
presents a main menu (see Figure 6) con¬ 
taining commands that can be invoked 
directly. Those that deal with messaging 
and editing are indicated with arrows in 
Figure 6. 

When using the picture acquisition 
icon, the user can place a new picture 
under the scanning device and order digi¬ 
tizing of the image. The image can then be 
sorted on the disk attached to the scanning 
device and transmitted to the workstation, 
where it is automatically displayed. Before 
deciding to the store the picture, the user 
can clean it up with the editor and store all 
or parts of it. 

When using the real-time messaging 
icon, a window opens at the workstation. 
The user can enter the destination name 
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Figure 7. Multimedia editor menu. 



(individual or group name) and the text of 
the message, transmitted directly over the 
local network to the destination. If the 
recipients of the message have initiated 
voice output (possible only at worksta¬ 
tions equipped with the voice synthesis 
feature), the arriving message is translated 
directly into spoken words. This service, 
also called Interphone, benefits a group 
work environment. Recipients can be so¬ 
licited for a meeting or to execute a specific 
task. The speaker icon allows the user to 
authorize or forbid speech synthesis. 

The slide preparation and presentation 
graphics editors provide tools for produc¬ 
ing information materials one page at a 
time. Although they can be invoked and 
executed independently, the modules are 
also embedded in the multimedia editor. 
When activated, this editor displays the 
menu shown in Figure 7. The menu con¬ 
tains commands for creating text blocks 
and for joining, manipulating, and brows¬ 
ing these blocks. Figure 7 highlights three 
particular types of command: image, 
voice, and presentation graphics. Blocks 
containing images can be retrieved from 
the filing system or digitized. The image 
can be placed anywhere. 

The image editor is probably one of the 
most powerful tools we have. The menu 
shown in Figure 8 illustrates the rich set of 
functions provided. All geometric trans¬ 
formations can be applied to various ob¬ 
jects. Each transformation has its own 
submenu. In Figure 8 we see two typical 
submenus, one indicating the different 
modes of scaling and the other, the library 
of textures available. Any object can be 
slanted and combined with other objects, 
which simplifies adding captions to pic¬ 
tures or creating images such as that 
shown in the middle of Figure 9. 

Since it is difficult to show how voice is 
created, we describe in written form the 
whole process. In voice mode, an open 
window accepts two types of data: written 
text to be synthesized, or digitized voice at 
64K-bits per second. The voice annotation 
can be modified only when in the text 
mode. Once created, it is stored in an at¬ 
tached address. In this respect, it is pro¬ 
cessed in the same way as a footnote. 
When presented on a screen, the voice is 
pronounced only if the voice output is ac¬ 
tivated (as explained before). In the cur¬ 
rent block, a special marker indicates 
vocal annotation. The user can ask for 
display of the property sheet of any object 
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including a voice marker and, in this case, 
hear the attached comment. 

Protocols and message 
structuring 

The interaction among Agora com¬ 
ponents is through appropriate protocols 
located at the application layer in the ISO 
reference model. The interaction between 
two components (entities) is based on the 
client-server dialog mode. The server per¬ 
forms the service and reports the result to 
the client. The dialog between client and 
server takes place in an interactive mode. 
Each service is represented by an opera¬ 
tion code and arguments that are the pa¬ 
rameters necessary to perform the opera¬ 
tion. Protocol elements are transferred by 
a message transfer protocol, or MTP. The 
MTP uses session services to create and 
maintain a logical session between entities. 

Data transfer is performed on a one¬ 
way alternate mode on a logical session. 
The data encoding scheme derives from 
the NBS proposal for message format syn¬ 
tax encoding, 9 while the message content 
is structured according to SGML. 10 

The NBS protocol. The NBS standard is 
based on the fields model 9 that defines the 
message as a series of fields—more ap¬ 
propriate than the header and text model. 
Thirty-nine fields have been proposed and 
divided into three categories: Required, 
Basic, and Optional. The required fields 
must be present in all messages and must 
be processed by all CBMSs. 

In Agora we adopted the three fields 
From, Posted-date, and To. The Basic 
message fields need not be present in all 
■messages, but must be processed by receiv¬ 
ing CBMSs. Four basic fields have been 
implemented in Agora: Cc, Reply-to, Sub¬ 
ject, and Text. The last category. Op¬ 
tional, contains fields that need not be 
present in all messages and may be ignored 
by receiving CBMSs. 

We implemented 22 fields: Attach¬ 
ments, Author, Bcc, Circulate-next, 
Circulate-to, Comments, Date, End-date, 
In-reply-to, Keywords, Message-class, 
Message-id, Obsoletes, Originator-serial 
number, Precedence, Received-date, 
Received-from, References, Reissued- 
type, Sender, Start-date, Warning-date. 
The syntax in the NBS format is machine- 


readable, which makes it flexible, especial¬ 
ly when nontextual data is to be presented. 

The message is structured in two sets of 
data elements: Basic (ASCII-string, Date, 
End-of-constructor, Field, and Message) 
and optional data elements (14 types). We 
mention in particular Bit-string, Com¬ 
pressed, Property-list, Extension, and 
Vendor-defined because of their use in 
Agora. The envelope was implemented as 
a Vendor-defined data element. Other 
types, such as Extension or Property-list, 
could be considered for encoding voice 
and fax. Naffah and Mazoyer argued 
these options. 12 However, we adopted the 
SGML language for the message content 
structure because it better suits the nature 
of complex documents transported by the 
message systems. 

The NBS processor takes approximate¬ 
ly 2000 lines of Pascal. 

Message content architecture. The con¬ 
tent of the message is usually called Docu¬ 
ment. Within this message field all of the 
semantics of the message should be em¬ 
bedded. When we examined the office en¬ 


Figure 9. Example of 
a multimedia page. 


vironment and analyzed the documents 
exchanged, we found it mandatory to pro¬ 
vide (in CBMS) a rich document architec¬ 
ture and thus a sophisticated document 
representation for the following reasons: 

• Multimedia environment: Office 
documents may include text with a variety 
of languages and alphabets, geometric 
graphics, facsimile pictures, mathematics, 
chemistry, professional symbols, voice, or 
a combination of these data types. 

• Processing environment: Some of the 
documents will be stored in databases, 
which necessitates their storage in revis- 
able form. Other documents may be sent 
to formatting or printing systems. 
Therefore, they are sent with physical 
layout parameters, or in final form. 

• Logical environment: Documents 
may vary from a simple note or memo to a 
book of many volumes. Those logical enti¬ 
ties are built according to a tree structure 
of elements, which may have complex log¬ 
ical links in addition to the tree-like rela¬ 
tionship. Documents can also be linked 
together. 
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In Agora we 
adopted the SGML 
representation to 
encode the content 
of messages 
exchanged between 
UAs and message 
servers. 


For these reasons, document architec¬ 
ture should be chosen with great care. The 
first proposals for multimedia protocols 
came from the Arpanet community. 13,14 
Recently, international standards groups 
such as CCITT and ISO started working 
on document standardization and transfer 
protocols. At the CCITT, T73 is propos¬ 
ing a structure for mixed-mode teletex ser¬ 
vice. ECMA and ISO proposed ODA- 
ODIF (office document architecture and 
office documentation interchange for¬ 
mat). In addition, ISO is considering the 
SGML (Standard Generalized Markup 
Language), also elaborated upon by an ex¬ 
pert group called CLPT (Command Lan¬ 
guage for Processing of Text). Xerox has 
proposed Interscript. 15 The current posi¬ 
tion of the standards groups is to combine 
the two families. 16 

In Agora we adopted the SGML repre¬ 
sentation to encode the content of mes¬ 
sages exchanged between user agents and 
message servers. During the editing pro¬ 
cess, all documents are automatically ex¬ 
ternalized in SGML format and sent in the 
Text field of the NBS format to a remote 
message processing end. Documents re¬ 
trieved from mailboxes are internalized by 
UAs for editing or display on the screen. 


Interconnection with 
public message 
services 

The Telex case. The Telex network con¬ 
stitutes the largest text-exchange service in 
the world, with millions of telex worksta¬ 
tions in different countries. Actually, it is 
the simplest form of electronic message 


sending, distinguished from the present 
CBMS by the lack of a store-and-forward 
service. To enhance this service, the 
CCITT has adopted the Teletex service, in 
which simple telex terminals are replaced 
by sophisticated Teletex terminals having 
editing and storage capabilities. 

Whether telex today or Teletex tomor¬ 
row, it is essential that any CBMS aimed at 
a large community of users provide special 
ports to this “telematic” terminal. There¬ 
fore, we decided to include the telex inter¬ 
face in the Agora project and provide the 
interconnection of CBMS and telex ser¬ 
vices in both directions. The major 
challenge in accomplishing this is solving 
the problems of coexistence between two 
services with different levels of func¬ 
tionality at the terminal level. 

A telex agent built in special hardware is 
connected on one side to the telex net¬ 
work, where it is known by a unique inter¬ 
national telex number. On the other side it 
is connected to the Danube network, 
where it has a mailbox in the message 
server. The agent periodically polls its own 
mailbox to check the content. Whenever it 
finds a message, it takes it out and sends it 
through the telex network. When the 
agent receives a message from a distant 
telex terminal, it acts as an MPE and sub¬ 
mits the message to the appropriate mail¬ 
box in the message server. 

A naming convention has been 
adopted: The telex subscribers are 
registered under one group, called Telex, 
with each member having a simple name as 
his international telex number. The sender 
of a message from the Buroviseur or a 
telex terminal indicates the Agora naming 
structure after the telex number. 

Conversion problems arise when the 
content of the message sent by a Burovi¬ 
seur contains data types that cannot be in¬ 
terpreted by the telex terminal. The telex 
UA identifies these data types (graphics, 
voice, facsimile) and replaces them with 
textual comment, indicating to the 
destination that parts are missing. 

Interconnection to public MTS. Re¬ 
cently, CCITT adopted a model of mes¬ 
sage handling, or MH, services the ad¬ 
ministrations will provide to enable 
subscribers to exchange messages on a 
store-and-forward basis. 

Two MH services are offered. The inter¬ 
personal message service supports inter¬ 


personal communication, while the mes¬ 
sage transfer service, or MTS, supports 
transfer of messages independently of ap¬ 
plication. Recommendations X.400 11 
define the protocols that apply between 
system components. 

An originator prepares and submits 
messages with the assistance of an applica¬ 
tion process called the user agent. The 
MTS delivers the messages to one or more 
recipient UAs. UAs interact with MTS 
using the submission and delivery proce¬ 
dures defined in the P3 protocol (recom¬ 
mendation X.411). MTS consists of a 
number of message transfer agents, or 
MTAs, that operate together to accept 
messages from originating UAs, relay 
these messages, and deliver them to recip¬ 
ient UAs. MTAs interact according to 
protocol PI (recommendation X.411). 
The interpersonal message service pro¬ 
vided by the UAs in cooperation uses pro¬ 
tocol P2 (recommendation X.420). Figure 
10 shows a layered representation of this 
model, the various cooperating entities, 
and the types of protocols that apply. 

To promote this model in France, the 
French PTT laboratory CNET launched a 
project called Cosac to interconnect ex¬ 
isting CBMSs according to the standard 
protocols. We were asked to make Agora 
compatible with these protocols. The basic 
choices made include 

(1) Agora should apply PI and P2 pro¬ 
tocols to exchange messages with MTS 
and provide interpersonal message service 
to end users. 

(2) The naming strategy for Cosac used 
country-name: Fr; administrative-do¬ 
main-name: PTT; private-domain- 
name: rva. For Agora, country-name: Fr; 
administrative-domain-name: PTT; pri¬ 
vate-domain-name: agora. 

(3) In terms of functions, we selected 
common functions provided by both ser¬ 
vices. For some functions not provided by 
Agora, we could only generate the cor¬ 
responding protocol element (such as 
Probe), but could not carry out the pro¬ 
cessing upon reception. On the other 
hand, some functions provided by Agora 
were not authorized to pass through the 
Cosac gateway. The following lists the 
functions supported at both PI and P2 
levels: 

(a) message transfer services, PI level— 
Basic (message identification, nondeliv¬ 
ery notifications), Submission and Deliv- 
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ery (delivery notification, delivery time 
stamp, disclosure of other recipients, 
grade of delivery selection, multidestina¬ 
tion delivery, prevention of nondelivery 
notification, submission time stamp), and 
Query (Probe-generated only), and 

(b) UA cooperation services, P2 level — 
Basic (basic message transfer service 
elements, user message identification, 
typed body), Submission and Delivery 
(same as message transfer service), 
cooperating UA information (originator 
indications, primary and secondary recip¬ 
ient indications, importance indication, 
sensitivity indication, subject indication), 
and Query (Probe-generated only). 

The implementation has taken the form 
of a dedicated gateway composed of three 
modules: 

• an MPE to interface Agora com¬ 
ponents, 

• a conversion module to perform the 
adaptation of functions and pro¬ 
tocols, and 

• an MTA to interface Cosac with PI 
and P2 protocols. 

The gateway was written in Pascal under 
the UCSD system. A proprietary real-time 
executive was added to deal with concur¬ 
rent tasks. The executable code occupies 
80K bytes of memory. 


A gora took a long time and covered 
a number of interesting areas in 
office systems, including distrib¬ 
uted systems architecture, with particular 
algorithms for updating distributed 
databases (name servers) and solving the 
consistency problems; multimedia mes¬ 
saging; conversion between services of dif¬ 
ferent qualities; man-machine interface 
consistency to the same service across dif¬ 
ferent types of terminals; and validation of 
X.400 recommendations (PI and P2) in a 
heterogeneous environment. 

The lessons we learned during this ex¬ 
perience have influenced most of the pro¬ 
totypes and products currently under de¬ 
velopment in different research centers in 
France. However, many issues remain 
needing solutions and many solutions 
need refinement. 

In distributed systems, we encountered 
major problems in name management in 
distributed directories and the introduc¬ 
tion of a new set of high level protocols in 
the system components. The management 



Figure 10. CCITT model 
and Agora as a private 
domain. 


of names should satisfy two conflicting 
criteria: service flexibility and directory 
consistency. The service should be flexible 
enough to allow the user to change his at¬ 
tributes whenever he wishes to do so and at 
the same time, keep data consistent in the 
distributed databases of directories. We 
proposed an algorithm to solve this prob¬ 
lem. However, work should continue to 
validate the scheme in a real international 
environment, where public and private 
directories will work together. 

The other issue concerns the X.400 pro¬ 
tocols (PI, P2, and P3) proposed by 
CCITT. The introduction of these proto¬ 
cols led to the addition of 80K bytes of 
code to the protocols of the five other 
layers of the open system architecture. We 
believe that an economical solution would 
be to split the functions into two parts, the 
user interface and protocols management. 
We would put the former into the work¬ 
station and the latter into a dedicated 
server shared by a group of workstations 
located at the same site. 

We have shown this concept to be feasi¬ 
ble in the multimedia area. Few other sys¬ 
tems have launched similar projects. 17 

Two issues need solution before putting 
these systems into real offices. The first 
deals with ergonomics, or human interac¬ 
tion with multimedia documents. Current 
solutions for display seem acceptable, rely¬ 
ing on menus, icons, and windows. How¬ 
ever, interaction with voice segments 
remains in its infancy. We have seen that 
customization of the workstation by autho¬ 
rizing or prohibiting voice is an important 
feature, but we don’t yet know the impact 
of editing voice in communal situations. 


The second issue relates to the ability 
of multimedia systems to be generalized, 
with adequate workstation support in 
the office. The present situation looks 
very promising for graphics, and we all 
expect a spectacular evolution there. 
However, the embedding of voice in com¬ 
mercial systems messages remains uncer¬ 
tain. We shall simply have to wait and see 
what happens. □ 
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An Invitation to the 
World of PAX 


Tsutomu Hoshino, University of Tsukuba, Japan 


Using contemporary 
LSI and simple 
architecture, we can 
construct a multiple- 
purpose machine PAX 
with a 1 Gflops speed. 
Our goal for the 
1990's: a 1 Tflops PAX. 


O ne of the most popular research 
and development topics in com¬ 
puting is the exploitation of par¬ 
allelism in processing computationally in¬ 
tensive applications and the creation of the 
necessary super-high-speed computer. 1 
PAX computer development, while simi¬ 
lar to other attempts to create a super- 
high-speed computer, is somewhat dif¬ 
ferent in approach. 

The PAX computer project, sponsored 
by the Japanese Ministry of Education, 
was started in 1977 by me and Prof. T. 
Kawai, Keio University. It aimed at the 
realization of a high-speed multi-micro- 
processor system that could calculate the 
power distribution in the Boiling Water 
Reactor (BWR) by solving the coupled 
neutronic-thermo-hydraulic equations 
that describe the three-dimensional reac¬ 
tor core. This goal was attained when 
PACS-32, an array of 32 microprocessors 
connected in a two-dimensional, nearest- 
neighbor-mesh, 2 performed a successful 
load-follow analysis of the BWR. 

The method of parallel processing used 
was very straightforward and traditional 
in that it took advantage of the locality of 
the physical process and the proximity of 
the physical actions: The physical space 
was directly mapped onto the processor 
array, and each processor executed its own 
mapped local task with proper exchange 
of data between the adjacent processors. 

During the development of PACS-32, 
there were indications that PACS architec¬ 
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ture could be effective for a multi¬ 
purpose, parallel computer covering the 
greater part of all scientific and engineer¬ 
ing applications. The name “PACS” 
(Processor Array for Continuum Simula¬ 
tion) was later changed to “PAX,” which 
stands for Processor Array experiment; 
four hardware PAX prototypes (with 9, 
32, 64, and 128 processors, respectively) 
have been constructed so far. The newest 
PAX prototype, the PAX-64J, is an 
industry-made, commercial version with 
64 DCJ11 microprocessors. Nowadays, 
the PAX prototypes are used intensively in 
studies aimed at developing algorithms to 
be used with PAX-type architecture in 
solving scientific-application problems. 

As evidenced by the June 1985 issue of 
Computer , 1 the scope of parallel-process¬ 
ing research and commercial development 
is expanding; it spans from commercial 
supercomputers with vector-processing 
capability to highly parallel multi-micro¬ 
processor systems for limited application. 
It is obvious that all the growth is strongly 
dependent on the progress of LSI technol¬ 
ogy. The recent, innovative CMOS tech¬ 
nology will definitely influence multipro¬ 
cessing architecture in the sense that device 
technology is fundamental and is some¬ 
times the most crucial economic factor. 
CMOS technology favors the highly paral¬ 
lel construct; it is shifting the R&D spec¬ 
trum toward higher parallelism in both 
commercial supercomputers and special¬ 
ized multiprocessor systems. 
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Figure 1. Direct mapping of physical space onto a PU array. 
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Figure 2. Modular mapping of physical space onto a PU array. 


A user's approach to 
PAX architecture 

Basic concepts. We have retained the 
user’s view in pursuing this project: We 
think about the architecture and evaluate 
performance with reference to our own 
applications. The architecture is not new 
in the academic sense (that is, it does not 
embody a new theory), but it must none¬ 
theless work for practical applications. 
The machine is intended to be used for 
several representative applications—to be 
a multipurpose machine rather than a 
special-purpose machine. 

The most critical aspect of parallel pro¬ 
cessing on PAX is mapping. This is the 
process of decomposing a job into sub¬ 
tasks that can be executed in parallel and 
allocating the sub-tasks to the processing 
units (PUs) and memory elements. 

What mapping is suited for numerical 
simulation of the continuum (fluid, 
material, field, etc.), which is represen¬ 
tative of many scientific applications? A 
PU array interconnected by a nearest- 
neighbor-mesh (NNM) makes use of the 
most prominent feature of physical 
models, the proximity property, which 
results from the fundamental principle of 
“action through a medium.” This princi¬ 
ple states that physical action always 
comes from the immediate medium and 
that there is no direct action from a remote 
medium. One practical way of mapping 
that retains this proximity property is 
direct mapping, in which the continuum is 
divided into subregions of the number of 
processors, as shown in Figure 1. 


One assumes in direct mapping that a 
simple correspondence exists between 
physical (phase) space, a numerical algo¬ 
rithm, and a computer architecture, such 
that the physical process in a subspace 
around point i is represented by the £th 
variable and is calculated by processor j. 
The physical interaction going on around 
point i requires that there be correspond¬ 
ing data communication between pro¬ 
cessor j and one of the nearby processors 
(nearby processors are defined as those 
directly connected to processor j). 

Another mapping that maintains the 
proximity property is modular mapping, 
in which lattice points are assigned to the 
processors as shown in Figure 2 (lattice 
points are grouped so as to reflect the size 
of the PU array). Both modular and 
direct mappings were proved successful 
in Illiac IV applications. 

Many scientific models have the prox¬ 
imity property. These models require as 
many as 100 x 100 x 100 lattice points or 
more, so there is no practical limit to the 
number of PUs required. This suggests the 
feasibility of using highly parallel com¬ 
puters with more than 1000 PUs. Also, 
this fits well with VLSI technology, which 
provides the most economical use of VLSI 
chips when a large number of identical 
chips are used. 

The other prominent feature of models 
of physical processes is that once an in¬ 
teraction between points in space or 
system components has been determined, 
each process can evolve locally, hence in¬ 
dependently of other processes. This 
autonomy is best utilized by the multiple- 
instruction, multiple-data (M1MD) archi¬ 


tecture, but not fully by the single-instruc¬ 
tion, multiple-data (SIMD) structure. The 
SIMD architecture limits itself to those ap¬ 
plication models in which parallel tasks 
consist of exactly the same instructions 
(these instructions are executed syn¬ 
chronously). Some processors can skip 
task execution simply by being idle. This 
mode of parallel processing is called vec¬ 
torized processing and the parallelism ex¬ 
ploited is very limited. 

In practical (that is, non-hypothetical) 
applications, physical processes occurring 
simultaneously are not always well adapted 
to SIMD parallel processing. In fluid 
dynamics, for example, the process in each 
point of space may be found to differ 
when a table lookup is made as a function 
of the state variable. The process in each 
point of space in a weather forecast model 
may differ when numerical scheme 
branches depend on the local atmospheric 
condition. 

Particle models are commonly full of 
conditional branches. One type of branch¬ 
ing generally depends on geometrical data, 
and the other type depends on variables 
associated with random processes on 
particles. 

The autonomy of physical processes 
clearly fits an MIMD or a quasi-MIMD 
computer structure. Though the SIMD 
structure simplifies the hardware, it is a 
drawback in terms of applications be¬ 
cause it does not enhance algorithm im¬ 
plementation. 

However, this does not mean that a 
computer structure must be truly MIMD 
in style. A common case for models of 
scientific applications is one in which 
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several synchronization points appear 
during the course of a computation and 
different processes appear only between 
successive synchronization points. This 
type of parallel processing (shown in 
Figure 3) can be thought of as “quasi- 
MIMD” mode. Individual procedures are 
executed in parallel in this model. The 
granularity is greater than that of the Illiac 
IV, where the same instructions are exe¬ 
cuted in parallel in each processing 
element. 

True MIMD mode is a mode of execu¬ 
tion in which parallel processes are com¬ 
pletely different and their execution is 
quite asynchronous. MIMD operation is 
not easy to design, program, and debug. 
However, quasi-MIMD operation is easy 
to consider, implement, and execute, and 
it is sufficient for scientific applications. 

Hardware and software summary. 

Since detailed descriptions of PAX hard¬ 
ware and software are given in other docu¬ 
ments, 3>4 this discussion is limited to ar¬ 
chitectural and algorithmic relations. 
Table 1 summarizes the hardware and 
software performance of PAX computer 
systems. 


Hardware. The basic PAX computer 
system consists of the PU array with the 
Control Unit (CU). Figure 4 shows how 
this basic structure fits into the PAX-128 
configuration. Figure 5 depicts the struc¬ 
ture of each PU, as typified by the 
PAX-128 architecture. There are several 
memory elements—communication mem¬ 
ories (CMs) and local memory (LM)—and 
registers—status register (SR), control 
register (CR), and synchronization register 
(SYNC)—in each unit. 

The machines presently operating are 
the PAX-32, with 32 PUs; the PAX-128, 
with 128 PUs; and the PAX-64J, with 64 
PUs. These PAX prototypes have almost 
the same architecture, that is, two-dimen¬ 
sional rectangular, end-around NNM- 
connection of PUs, and a single broadcast 
bus going through all PUs. 

The topological structure of the whole 
PU array is that of torus, which may be 
called a three-dimensional structure. The 
end-around connection is convenient for 
norm calculations, such as the summation 
or the maximum/minimum value of vari¬ 
ables distributed in the PU array. It is 
effective too in treating the periodic¬ 
boundary conditions that appear fre¬ 


quently in physics applications. Local con¬ 
nections are NNM in four directions in the 
two-dimensional plane of the torus. 

In a typical one-dimensional ring con¬ 
nection of P PUs, the maximum overhead 
associated with the trans-array data shift is 
proportional to P/2. In a two-dimensional 
array, this is proportional to P 1/2 , and in a 
three-dimensional array, to 3 P 1/3 /2. For a 
typical number of PUs, say 1024, the ratio 
of shifting time for one-, two-, and three- 
dimensional arrays is 512:32:15. The im¬ 
provement from one to two dimensions is 
great; the improvement from two to three 
is not as attractive. The work of wiring the 
PUs in one, two, and three dimensions is 
easy, moderate, and difficult, respective¬ 
ly. Our choice was a two-dimensional ar¬ 
ray implemented close to the logical struc¬ 
ture (as shown in Figures 6(a) and 6(b)), 
which realizes the shortest wiring distance 
for connecting the neighboring PUs. 

Nearest-neighbor PUs communicate by 
means of communication memories (CMs) 
that they share. The global two-phase 
clock signal drives all PUs in PAX-32 and 
PAX-128 systems, while the clock signal is 
generated locally in each PU in the PAX- 
643. Control of access to the shared CM is 


Table 1. Hardware and software performance of PAX computer systems in current operation. 


Component 

PAX-32 

PAX-128 

PAX-64J 

Host computer 

TI990/20 

TI990/20 

PDP-11/24 

Control unit 

Cosmo Terminal D 

Cosmo Terminal D 

— 

Number of processing units 

Processing unit information: 

32 

128 

64* 

Microprocessor 

MC6800 

MC68B00 

DCJ11 

Clock frequency 

1 MHz 

2 MHz 

15 MHz 

Attached processor 

AM9511A 

AM9511A-4 

— 

Memory capacity/PU 

18K bytes 

32K bytes 

136K bytes 

Memory access time 

450 ns 

150 ns 

. 55-45 ns 

Peak performance 

0.5 Mflops 

4 Mflops 

6.4 Mflops 


Time required to 

Time required to 

Time required to 


perform function on 

perform function on 

perform function on 

Function 

PAX-32 

PAX-128 

PAX-64J 

Synchronize all PUs 

138.0 ms 

47.5 ms 

18.200 ms 

Broadcast 1024-byte data 

40.0 ms 

40.0 ms 

9.000 ms 

A=A*B+C 

275.0 n$ 

137.5 ms 

30.700 ms . 

A(I) = B(I)*C(I) + D(I) 

Solve linear equation 

482.0 ms 

241.0 ms 

37.000 ms 

with 256 variables 
by Gauss-Jordan method 

2.6 s” 

17.1 S 

10.220 s 

Cascade sum of data 
stored in all PUs 

2.6 ms 

1.2 ms 

0.672 ms 


* Currently, 32 PUs are installed. 
** For 64 variables 
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South Processing Unit 


Figure 5. Configuration of the PU architecture of the PAX computer, as exemplified by the 
PAX-128. 


gained by means of the two-phase clock 
signal in PAX-32 and PAX-128 machines. 
The PAX-64J machine has a two-port CM 
with a first-come-first-served arbiter. 

Control and monitoring of the PU array 
is carried out by the control unit (CU), a 
microcomputer of the same type as the PU. 
The PAX-64J has no CU; the hardware in¬ 
terfacing the PU array with the host com¬ 
puter is in charge of these functions. 

The major control tasks are synchroni¬ 
zation of all PUs, data broadcasting to all 
PUs from the CU or from a source PU, 
monitoring the registers in PUs and re¬ 
sponding to the information written there 
(such responses are made, for example, at 
the end of a job or when other changes in 
the status of a PU occur). There is a hard¬ 
wired logic circuit that can detect the syn¬ 
chronization requests from PUs by per¬ 
forming logical operations on the codes 
written in the SR and SYNC registers. 
This hardware function reduces the sys¬ 
tem overhead associated with parallel 
processing. 

The CM is treated as an ordinary (that 
is, conflict-free) memory by a processor. 
Using the CM for inter-PU communica¬ 
tion avoids the overhead for data transfer, 
which is present in communication 
schemes that are less direct. 


Software. Users write main programs in 
Fortran for the host machine, while PU 
programs are written in the SPLM lan¬ 
guage for PAX-32 and PAX-128 comput¬ 
ers. The PAX-64J has a unified memory 
space for both the host and the PU array, 



Figure 6. Front view (photo on left) and side view (photo on right) of the PAX-128 system. (A front view of the panel on which the logical 
structure and execution status appear is shown in the left-hand photo; the back of the panel appears at the right of the right-hand photo.) 
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so a program can be implemented as a 
combination of main program for the host 
and subroutines for PUs, both written in 
Fortran. The memory space assigned to a 
PU array appears to the host computer as 
a special memory capable of parallel 
processing. 

The SPLM language is conventional ex¬ 
cept that it assigns variables to different 
memory spaces and registers. SPLM does 
not have special statements that explicitly 
command the parallel processing. 

One program is loaded in all PUs in 
most applications performed on the PAX 
prototypes, although it is possible for dif¬ 
ferent programs to be stored and executed 
asynchronously in different PUs. Each 
PU program describes how data are taken 
from the CMs, how they are processed, 
and how they are replaced in the CMs. The 
description is specific to each PU, and 
does not command the whole parallel 
process. 

Communication between PUs is ex¬ 
pressed simply—as if the data were written 
to local memory. The continuum models 
generally execute almost identical tasks in 
all PUs, with synchronization immediate¬ 
ly before each data transfer. The syn¬ 
chronization is commonly used as a 
semaphore to avoid access contention 
when the data are transferred between ad¬ 
jacent PUs. The mechanisms for data 
transfer between neighbors and for syn¬ 
chronization keep overhead small. The 
communication via “rendezvous” of 
parallel processes is seldom necessary, 
which avoids the overhead associated with 
this technique. We use simple solutions to 
problems whenever possible. 

In addition to NNM communications, 
data broadcasting from any single PU to 
the entire PU array is necessary for some 
algorithms, such as Gaussian elimination. 
One hardware function of the copy com¬ 
mand is the repetition of this broadcasting 
until the data distributed over all PUs are 
copied to each PU. Since a global bus is 
necessary for initial program loading, the 
broadcast bus doesn’t need extra hard¬ 
ware. 

Parallel processing in PAX depends on 
the parallelism inherent in the physical 
process under simulation. The architec¬ 
ture is designed to approximate the phys¬ 
ical process to be simulated by the com¬ 
puter, with the result that the burden on 
the software (and the user) to span the gap 


between computer and application be¬ 
comes smaller. 


Algorithm and 
application summary 

An experiment-oriented approach. We 

chose to use “the proofs of experimental 
science” rather than “computer scientists’ 
speculation” in evaluating the perfor¬ 
mance of PAX computers. We carry out 
our decision through (1) implementation 
of representative application problems in 
the real machines, (2) analysis of programs 
to determine the formula for execution 
time for parallel processing, (3) determina¬ 
tion of the coefficients in the expression by 
measuring the execution time of all or part 
of the program with a hardware timer, and 
(4) validation of the scaling law. We will 
extend the proven performance to future 
large-scale application problems and solve 
them with future machines with larger 
numbers of PUs with faster computa¬ 
tional speeds and data-transfer rates. 

This rigorous approach (that is, one re¬ 
quiring proofs) is necessary, and it is prac¬ 
tical. Even when the order of complexity 
of the overhead is greater than that of the 
net calculation, it is practical if the coeffi¬ 
cient of the overhead term is so small that, 
for design parameters and problem sizes 
that are realistic, overhead remains small 
compared to the net calculation time. 

“Consistency” of parallel algorithms. 

Linear recursive equations appear very 
frequently in the algorithms used in scien¬ 
tific calculations, and they are probably 
among the most difficult computations 
for parallel processing. 

A simple example, that of summing A 
scalar variables by the well-known cascade 
sum method, 5 illustrates the difficulty of 
applying parallel processing to the more 
complex recursive algorithms, such as 
Gaussian-elimination when it is used to 
solve tridiagonal linear equations. 

Suppose that we have A processors con¬ 
nected in a one-dimensional, nearest- 
neighbor ring structure, and that each 
processor is assigned one variable. (A is as¬ 
sumed to be a power of 2; A= 2".) 

Each variable is shifted cyclically the 
distance of 2* PUs, and the shifted 
variable is added to the variable stored 
before the shift. The process is repeated in 


Parallel processing in 
PAX depends on the 
parallelism inherent in 
the physical process 
under simulation. 


k = 0, 1, .... n stages. When the process is 
completed, each processor has the sum of 
all variables originally allocated to the pro¬ 
cessors. This cascade scheme consists of 
n = log 2 A stages, where each processor 
executes one addition (A serial additions 
executed in parallel). The total number of 
serial additions, Alog 2 A, is executed by A 
processors. 

As for the inter-processor data transfer, 
the scheme includes 1,2,..., A/2 parallel 
data shifts, for the first, second, ..., 
log 2 Ath stages, respectively. The total 
number of shifts executed in parallel is 
A-1. The total parallel execution time, 
therefore, is dog 2 A+Z)(A-1), where C 
is the time for addition, and D is the data- 
transfer time. Serial algorithms use A-1 
additions with no data transfer. 

The traditional way of evaluating paral¬ 
lel-processing complexity is to ignore the 
inter-processor data transfer and to as¬ 
sume the availability of as many proces¬ 
sors as we need. The Mog 2 A serial addi¬ 
tions are executed by A processors, so the 
complexity of the cascade scheme is 
0(log 2 A). This is smaller than the serial 
complexity, 0(A), hence we have a 
speedup of 0(A/log 2 A). 

The actual complexity, however, is dif¬ 
ferent from this, since it involves a fixed 
number of processors, say P. The total time 
for 0(Alog 2 A) summations executed by P 
processors in parallel is 0((Alog 2 A)/P), 
which is greater than the serial complexity. 
Since the number A tends to be large, the 
cascade sum will take much more time than 
the serial scheme. 

Lambiotte proposed the concept of 
“consistency” of parallel algorithms, 6 
that is, a parallel algorithm is ‘ ‘consistent” 
if its order of complexity is equal to that of 
its corresponding serial algorithm. In this 
framework, the cascade sum scheme is not 
consistent, and the parallel cascade sum is 
thus less attractive than the serial summa- 


May 1986 


73 










An algorithm must be 
"consistent" to be 
practical for solving 
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tion for applications involving a large 
number of variables, as pointed out by 
Hockney and Jesshope. 5 

However, there are several methods for 
making the scheme consistent. One method 
is similar to that pointed out by Lam- 
biotte, 6 in which the set of variables is par¬ 
titioned into P sets of variables, each hav¬ 
ing N/P variables. (N/P is assumed to be 
an integer.) As a first step in this method, 
the serial addition of N/P variables is 
made in parallel in each processor; the 
complexity is 0(N/P). Then the P partial 
sums are put into the cascade sum scheme, 
which results in 0(log 2 P) + 0(P) com¬ 
plexity when P processors are used. The 
total complexity of the scheme is 0(N/P) 
+ O(log 2 P+P), which is the same as 
O (N) because Pis a fixed parameter. 

The more common way, which is used 
in the pipeline computer, requires that one 
first take the summation of variables 
stored P steps apart, where P is the 
number of pipeline stages. (Note that there 
is no interaction between data residing at 
the different stages of the pipeline, hence 
no recursion is involved in this summa¬ 
tion.) Then the P partial sums are added 
by the conventional serial scheme, which 
has a complexity of 0(P-1). The total 
complexity is again 0(N/P) + 0(P- 1): 
The scheme is consistent! 

Note that this example of summation is 
not recursive at all, since it is not necessary 
to add the variables in a certain predeter¬ 
mined sequence, as is the case with tridi¬ 
agonal linear equations. However, an ex¬ 
tension of the method is possible for truly 
recursive cases, as I will show below in il¬ 
lustrating the ADI scheme for parallel pro¬ 
cessing, which is implemented in the PAX 
computer. 


Note also the necessary data-transfer 
overhead. Data-transfer overhead has a 
complexity of 0(P), which could over¬ 
whelm the total execution time because the 
number of processors, P, tends to be very 
large. 

As we have seen, the success of parallel 
processing is dependent on whether we can 
construct a scheme with either low com¬ 
plexity or small coefficients for redundant 
calculations—or whether we can construct 
a “consistent” implementation of the 
algorithm. 

All these conditions are strongly depen¬ 
dent on each particular application model 
and computer architecture. That is why we 
must actually implement application pro¬ 
grams to evaluate the performance of a 
parallel computer. As a general guideline, 
we can say that an algorithm must be con¬ 
sistent to be practical for solving large- 
scale scientific problems on multiproces¬ 
sors with a limited number of PUs. 

Experiments and performance measure¬ 
ment. The applications tested thus far on 
PAX machines are summarized in Table 2 
and are described below. Although these 
applications are simple and small in size, 
they represent large-scale problems accu¬ 
rately because the PAX technique used in 
each case can be scaled to the sizes of both 
the problem and the processor array. Al¬ 
though models that lack the proximity 
property are still believed to be inappro¬ 
priate for the PAX computer (owing to 
inefficient remote or global data transfer 
among PUs), our experiments prove that 
they can be processed with reasonable 
efficiency. 

In the following discussion, the para¬ 
meter Pis used for the total number of PUs 
connected into a square array of size P /l , 
and the parameter N is used for the repre¬ 
sentative size of the problem (such as the 
total number of lattice points or particles). 

If not otherwise specified, the ratio N/P 
is considered to be a constant parameter. 
This is an assumption that will be made by 
those users who will assess our future 
machines: Given a fixed ratio of N over P, 
how do the speedup and efficiency change 
as P becomes large? These users wish to ex¬ 
pand the problem size if given a larger 
machine, because the degree of parallelism 
available in the machines they will use for 
some time to come is smaller than that 
which is inherent in their application 
models. 


Solving Poisson equations with the SOR 
method . 4 Many application problems 
require solutions to two-dimensional Pois¬ 
son problems in their innermost loops. We 
solved Poisson equations on PAX by using 
the well-known SOR (successive over-relax¬ 
ation) method, which incorporates odd- 
even ordering. 

The method is an iterative method in 
which each point is updated explicitly. The 
SOR method capitalizes on the proximity 
property and supports substantial paral¬ 
lelism. 

Physical space is directly mapped onto 
the PU array in this scheme. The efficiency 
becomes asymptotic to unity as N/P (the 
number of lattice points per PU) grows 
large. This follows because the overhead on 
inter-PU data transfer is proportional to 
the boundary length— (N/P) ' A —of the 
subregion mapped to a PU, while the net 
calculation time is proportional to N/P, the 
area of the subregion. Hence, the ratio N/P 
is directly related to efficiency, so as long as 
the ratio is kept constant, the efficiency also 
remains the same and linear speedup is 
realized as the number of processors in¬ 
creases . Our observation of PAX computer 
performance proves that the machine is well 
matched to this “iteration and proximity” 
type of problem. 

Solving Poisson equations with the ADI 
method. 1 We solved a two-dimensional 
Poisson equation on PAX by an implicit 
method, the Alternating Direction Implicit 
(ADI) scheme. The method is used to solve 
implicitly tridiagonal linear equations in x 
and y directions alternately. 

The well-known method for achieving a 
consistent parallel ADI scheme is the 
skewed-mapping 8 of a multidimensional 
physical space onto a ring array of PUs, 
which is the structure of the Illiac IV. 
Though skewed-mapping is effective on 
machines with a relatively small number of 
processors, it is less attractive for highly 
parallel computers with large numbers of 
processors (say 1024). That is because: 

1) The original space may not be large 
enough to be divided into more than 1024 
slices. 

2) Even if the original space is large 
enough, the greater part of the execution 
time will be spent in the diagonalization 
process, which can be executed in parallel at 
all lattice points. The parallelism here is 
equal to 1024 x 1024. This inherent parallel¬ 
ism cannot be fully exploited by 1024 PUs. 
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A better mapping for highly parallel 
computers is direct mapping. The nearest- 
neighbor array, which PAX incorporates, 
was assumed to be inefficient for this type 
of scheme, since it requires the transposing 
of data distributed in the array or the solv¬ 


ing of linear equations by multiprocessors 
connected in a ring array. 

However, the well-known cyclic reduc¬ 
tion technique can achieve the implicit solu¬ 
tion with reasonable efficiency if the data 
are preprocessed by Gaussian elimination 


of inner points so that only the lattice-point 
data on the PU boundary take part in the 
cyclic-reduction scheme. This entire paral¬ 
lel scheme is called Gauss-Elimination- 
Cyclic-Reduction (GECR). 7 

When the parameter P is fixed to a con- 


Table 2. Performance of PAX computers in application problems. (These statistics were obtained through the actual measurements of 
execution times.) 




Features * 



Measurement 


Prediction 

Application 

problems 

Data Opera- 
transfer tional 

Work 


Problem size,* 2 

Execution time 
per iteration 
(s/iter).* 3 

Efficiency (%) PAX with P 0 

Asymptotic 

efficiency 
(N/P= 
constant as 

P(c* = 50%)*® 
with fixing, 

N/P= 

(algorithm) 

mode 

mode 

load 

Mapping 

N min ~ N max 

Tmin ~Tmax 

“min ~“ma 

K PUs: PAX-Pq 

P-oo) 

Nmax/Po 

Poisson equation 









0(1) 


(SOR) 

Prx 

Syn 

Unf 

2Dr 

16x16-48x48 

0.0016 - 0.011 66 - 89 

PAX-128 

OO* 7 




16x16-128x128 

0.0027 - 0.105 64 - 93 

PAX-64J* 4 

0(1) 

00* 7 

Poisson equation 










1600 

(ADI) 

Prx, Rmt 

Syn 

Unf 

2Dr 

32x32-48x48 

0.134 - 0.247 

65-72 

PAX-128 

0(P - 1/2 ) 



32x32-160x160 

0.069-1.19 

82-95 

PAX-64J* 4 

0 (P~' k ) 

10000 

Navier-Stokes 











(Beam 

Warming) 

Prx, Rmt 

Syn 

Unf 

2Dr 

32 x32 - 64 x64 

0.541-1.951 

89-94 

PAX-64J* 4 

0 (P~' k ) 

16000 

(MacCormack) 

Prx 

Syn 

Unf 

2Dr 

32 x 32 -64 x64 

0.238-0.900 

97-98 

PAX-64J* 4 

0(P~ Vi ) 

>10 6 

(SOLA) 

Prx 

Syn 

Unf 

2Dr 

16x32-32x64 

1.93-7.31 

74-87 

PAX-128 

0 (P - 1/2 ) 

>10® 

Linear equation 








PAX-128 

0(1) 


(G-J) 

Gib 

Syn,Brd Unf 

IDr 

128 - 640 

3.9 — 202(S) 

46-82 

OO* 7 

Linear equation 











(C-G) 

Gib 

Syn, Brd 

Unf 

IDr 

128 - 640 

0.102-0.553 

34-73 

PAX-128 

0(1) 

OO* 7 

Monte Carlo spin 

Prx, Rmt 

Syn 

Unf 

2Dr 

32x32-80x80 

0.927-8.51 

70-95 

PAX-128 

0(p-%) 

>10® 

U(1) lattice 











gauge 

Prx 

Syn 

Unf 

2Dr 

(2x2~8x8)x8x16 

0.578 - 8.72 

97-97 

PAX-128 

10(1) 

oo* 7 

Molecular 

dynamics 

(Lag) 

Gib 

Syn 

Unf 

IDr, Lag 

192-288 

6.77-15.5 

96-97 

PAX-32 

i 0(1) 

00*7 

(Eul) 

Gib 

Syn 

Nuf 

2Dr,Eul 

192-288 

8.23-17.4 

75-76 

PAX-32 

o(i/f)* 5 

oo* 7 

Plasma particle 









; 0(P -,/! log 2 P) 


field (FFT) 

Rmt 

Syn 

Unf 

2Dr 

512 

0.129{s) 

59 

PAX-128 

600 

particle push 

Prx,Rmt Syn 

Nuf 

2Dr,Eul 

2048 

0.083(s) 

65 

PAX-128 

! 0(1/0* 5 

OO* 7 

Unsteady flow 

Prx 

Syn, Ppl 

Nuf 

IDr 

384 

1.13 

56 

PAX-128 

0(1) 

00* 7 

Logic circuit 

Rmt,Irg Asy,Dtf 

Nuf 

2Dr 

416 (gates) 

0.0098(S) 

5 

PAX-128 

;0 (P~' k ) 

4 


* 1. Abbreviations used in this column are “Prx,” for proximity; “Rmt,” for remote; “Gib,” for global; “Irg,” for irregular; “Syn,” for syn¬ 
chronous; “Asy,” for asynchronous; “Ppl,” for pipeline; “Dtf,” for dataflow; “Brd,” for broadcasting; “Unf,” for uniform; “Nuf,” for 
nonuniform; “2Dr,” for two-dimensional direct; “1 Dr,” for one-dimensional direct; “Lag,” for Lagrangian scheme; and “Eul,” for 
Eulerian scheme. 

*2. Unless otherwise specified, problem size is measured in terms of lattice points or particles. 

*3. Unless otherwise specified, execution time per iteration is specified in units of (s/iteration, or s/time step). 

*4. Currently, 32 PUs are installed. 

*5. The factor f is the ratio of maximum to average particle densities. 

*6. P(a = 50%) stands for the approximate number of PUs that display 50% efficiency. 

*7. P will be limited by the propagation delay of synchronization signals, but will still be some value greater than 10 6 . 
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"Pivoting" is no 
problem with the PAX 
computer. A cascade 
comparison is applied 
to find the element 
with the largest 
absolute value, which 
then becomes the 
next pivot element. 


stant, simple application of the cyclic- 
reduction scheme has a complexity of 
0((Mog 2 A r )/P) for calculation and 
0(N/P 1/2 ) for data transfer. The serial ADI 
scheme has a complexity of O (N), so this 
cyclic-reduction scheme is not consistent. 

However, by preprocessing with Gaus- 
sian-elimination, the complexity of calcula¬ 
tions and data transfer reduces to 0(N/P) 
and 0(Af‘ /2 ), respectively, making the 
whole scheme consistent. Not only the 
order of complexity, but the overhead of 
data transfer itself is reduced by the 
decrease in the number of data brought into 
the cyclic reduction, resulting in better effi¬ 
ciency than would be obtained by simple 
application of the cyclic-reduction sheme. 

Solving Navier-Stokes equations with the 
Beam-Warming method. 1 The Beam- 
Warming method is an implicit-factoriza¬ 
tion method for solving Navier-Stokes 
equations that are applied to aerodynamics 
problems that involve shock waves. The 
method is essentially the same as the ADI 
scheme from the viewpoint of parallel pro¬ 
cessing; thus, the GECR method can be ap¬ 
plied to the innermost loop of Navier- 
Stokes tridiagonal equations. 

The measured performance of the total 
process is satisfactory: 90.7 percent effi¬ 
ciency for 64 x 64 lattice points. The lin¬ 
earization and diagonalization of the es¬ 
sentially nonlinear equations take almost all 
of the net calculation; during linearization 
and diagonalization, multiplication of the 
(dense) matrices is carried out at each lattice 
point at each iteration. This computation 
method is the major reason that efficient 
parallelization is achieved—even in the im¬ 
plicit scheme. Another factor that keeps ef¬ 


ficiency high in the implicit scheme is the 
GECR scheme, which is consistent. 

Though the efficiency degrades (1) as the 
number of PUs moves to infinity and (2) 
when there is a limit of a single lattice point 
per PU, the measured performance is satis¬ 
factory from the viewpoint of practical 
fluid dynamics, in which the parallelism in¬ 
herent in the application problem is much 
greater than that which can be supplied by 
the PAX computer for some time to come. 
MacCormack’s explicit scheme 9 and the 
SOLA 10 iterative scheme were also exe¬ 
cuted for purposes of comparison, and 
proved to have high efficiency. 

Solving linear equations with the Gauss- 
Jordan sweepout method. 3 This method is 
well-known. It can exploit parallelism be¬ 
cause the sweepout process can be executed 
in parallel in each row if the unknown vari¬ 
able^) are mapped to each PU. 

The transfer of the pivot-row data to 
other rows is done efficiently on PAX by 
broadcasting-type hardware. The high ef¬ 
ficiency is attributable to the denseness of 
the matrix. Where sparse matrices are con¬ 
cerned, the method has to process the “fill- 
in” (nonzero elements fill the sparse matrix 
as the elimination proceeds, and they even¬ 
tually make it dense), and the efficiency 
degrades. 

Pivoting is no problem with the PAX 
computer; a cascade comparison is applied 
to find the element with the largest absolute 
value, which then becomes the next pivot 
element. 

Note that the complexity of the parallel 
sweepout process is 0(N 3 /P), and that it is 
higher than that of the overhead associated 
with both the cascade-comparison process, 
Q(N/P Vl ), and with broadcasting, O (N 2 ).' 


Solving linear equations with the conju¬ 
gate-gradient method. 3 This iterative 
method includes a vector-vector inner 
product and a matrix-vector product. The 
mapping on PAX allocates an equal num¬ 
ber of variables to each PU. 

Global data-transfer is required to 
achieve results in some dense-matrix cases, 
while sparse-matrix cases need only nearest- 
neighbor data transfer if the linear equa¬ 
tions are derived from a discretization of 
the continuum and direct mapping is em¬ 
ployed in assigning points in space to the 
PU array. We encountered sparse-matrix 
cases while using the conjugate-gradient 


method to carry out finite element analysis 
of the two-dimensional elastic problem. 

Finite element analysis can be processed 
with high efficiency 11 if the discrete mesh 
has elements of regular shape and size (such 
as mesh elements that are all triangular). 
For practical cases with very irregular ele¬ 
ments, other mappings are needed (an ex¬ 
ample of such a mapping is that of the con¬ 
tinuum and associated banded-matrix to a 
one-dimensional PU array). These one-di¬ 
mensional mappings yield better agreement 
than two-dimensional mappings with 
established finite element programs, but are 
less parallel because the number of their 
PUs cannot exceed the number of elements 
in any one dimension of the continuum. 
PAX can accommodate this one-dimen¬ 
sional mapping by using only two of the 
nearest-neighbor communication links. 

The complicated structure often consists 
of several substructures, which are repeat¬ 
edly solved to reach the overall solution. 
The more practical finite element analysis 
(in which the substructure method is used) 
needs Gaussian-elimination of inner points 
in the substructure stages. In the final, over¬ 
all stage, the linear equation is solved with 
dense matrices, where PAX operates very 
efficiently. 

Monte Carlo simulation of spin mod¬ 
els. 12 Spin models, such as Ising or Heisen¬ 
berg models, are used to simulate ferro¬ 
magnetic material, which is represented as 
an array of spins interacting with each other 
through a quantum force coupling only the 
nearest-neighbor spins. 

The models are essentially the same as 
that of the continuum, except that the new 
state of the spin is determined randomly. 
(They are often called Monte-Carlo simula¬ 
tion models. ) The method (random deter¬ 
mination of the state of the spin) can be ap¬ 
plied to similar models in lattice-gauge 
theory that simulate quantum chromo¬ 
dynamics. For example, the preliminary 
U(l) gauge model was processed at very 
high efficiency: 96 percent. It incorporates 
direct mapping, as do the continuum 
models. 

The random determination of spin state 
on a Monte Carlo model was executed ef¬ 
ficiently in parallel with a complexity of 
0(N/P), although this includes the remote 
transfer of spin data in the calculation of 
the correlation between remote spins. This 
calculation of the correlation between 
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remote spins has the highest complexity 
of any subprocess for this problem— 
0(d P 1/2 )—and the complexity stems from 
the cascade summation for the correlation 
coefficient. (The parameter d is the distance 
of influence of spin correlation.) 

Though the efficiency of Monte Carlo 
models asymptotically goes to zero as P in¬ 
creases, it remains reasonably high for a 
practical spin-model size and a realizable 
PU array size. 

The molecular dynamics model . 13 The 
molecular dynamics model is processed by 
mapping either an equal number of par¬ 
ticles to each PU or an equal volume of 
physical space to each PU. We call the 
former method the Lagrangian scheme and 
the latter the Eulerian scheme. 

The Eulerian scheme suffers from a non- 
uniform distribution of particles over the 
PUs; the PU containing the space point 
with highest particle density becomes busier 
than other PUs, which eventually become 
idle. The efficiency, therefore, degrades as 
per the ratio of the average densities to the 
maximum densities of particles in PUs. A 
simple method for overcoming this ineffi¬ 
ciency is modular mapping of particles to 
the PU array, though it increases the 
overhead of data transfer. 

In the Lagrangian scheme, the work load 
is uniform, but all particle data must be cir¬ 
culated by either a toroidal shift or by a 
copy hardware mechanism to make certain 
that all particles meet each other. 

The toroidal shift, a trans-array move of 
data, consists of two ring shifts: An “east- 
west shift” performed until all PUs hold a 
copy of all data in their own row, and a 
“north-south shift” performed until all 
data are processed (or stored if necessary) in 
each PU. 

(Note that this circulation and the copy¬ 
ing of particle data take a time approx¬ 
imately proportional to the size of data N, 
not to the size of array P.) 

The force pushing each particle is derived 
from the differentiation of the potentials 
existing between all pairs of particles. An 
approximate calculation of these potentials 
can be made based only on those that exist 
between particles that are near one another, 
which requires a check of all pairs of 
particles for the distance between them. 
These calculations have a complexity of 
O (N 2 /P), while the overhead part, the 
toroidal shift of all particle data, has a lower 


complexity, O(N). Hence, the efficiency 
asymptotically goes to unity as the number 
of particles increases. 

The execution time naturally increases as 
O (N 2 /P) in the Lagrangian scheme. The 
Eulerian scheme has a complexity of either 
0(N 2 /P) or O (N 2 /P 2 ), depending on 
the order of the number of particles near to 
each particle— O(N) or O (N/P) in each 
respective case. The best method, there¬ 
fore, should be determined by considering 
how uniformly the particles are distributed, 
or how widely the potential function covers 
the whole space. 

Plasma-particle simulation . 14 Electrons 
in plasma are subject to the Coulomb 
potential that they create. This potential 
affects the surrounding physical space. A 
Poisson equation is solved by Fast Four¬ 
ier Transform (FFT) to determine the 
potential. 

When we carried out plasma-particle 
simulation on the PAX computer, the mea¬ 
sured efficiency degraded by a factor 
P 1/2 log 2 P, which was included in the 
FFT algorithm. Also, the efficiency was af¬ 
fected by the locality of particles when the 
mapping of particles followed the Eulerian 
scheme with direct mapping. The modular 
mapping can eliminate this locality effect. 

The extended scaling law of efficiency 
predicts that the scheme is feasible for a 
practical number of PUs that can be in¬ 
stalled under the present state of hardware 
technology. 

Pipeline processing 15 for simulating a 
flooding river. A simple programming 
method can be used to make the PAX com¬ 
puter execute a program in pipeline mode. 
The two-dimensional PU array acts as a 
one-dimensional array when one-dimen¬ 
sional coordinates are assigned to PUs and 
only two communication links are used. 

This pipeline processing scheme is such 
that, at time step t, only PUs with coordi¬ 
nates p< = t are executing the task asso¬ 
ciated with p and t; the rest of the PUs are 
idle. The program has the structure of 
IF p< = t THEN do task (p,t) ELSE do 
nothing. 

We solved the fluid-flow problem in one 
dimension by projecting lattice points onto 
a one-dimensional PU array. The algo¬ 
rithm is essentially recursive, that is, the 
processing of point of space p at time t re¬ 
quires the result of point p at time t - 1 and 
“upstream” and “downstream” neighbors 


A simple 

programming method 
enables the PAX 
computer to execute 
programs in pipeline 
mode. 


of p at time t. This process requires MIMD- 
type pipeline-mode processing. Theoreti¬ 
cally, the efficiency of pipeline processing is 
expressed by E=N/(N+P - 1), where A is 
the length of the vector passing the pipe and 
P is the length of pipe. The expression was 
confirmed by actual measurement. 

Logic-circuit simulation : 14 an asyn¬ 
chronous mode operation. Logic-circuit 
simulation, in which a number of logic de¬ 
vices are simulated by software, is a critical 
step in LSI development. The connections 
among devices are not always limited by 
proximity. 

Logic connections can be represented by 
a random, sparse matrix. We used direct 
mapping to make the number of devices per 
PU as uniform as possible. Data were 
routed according to a connection table. The 
routing was carried out asynchronously; no 
synchronization was done. The data trans¬ 
fer between the nearest neighbor PUs was 
also carried out by emulating First-In-First- 
Out (FIFO) devices, which were imple¬ 
mented in place of CMs. 

Tasks inside each PU were initiated on 
the PAX when data were ready; thus, a 
dataflow mode of operation resulted. The 
derived performance was encouraging. The 
asymptotic scaling law of speedup was pro¬ 
portional to P Vl for P>P,, and when 
P<P t , the speedup was linear with respect 
to P, where P, = (time needed to simulate 
one gate)/(time needed to transfer the data 
between the adjacent PUs). 2 Though 5 per¬ 
cent efficiency might seem to be too low, it 
is encouraging that the FIFO emulation in¬ 
dicated that a higher efficiency, 50 percent, 
would be obtained if we actually installed 
FIFOs. 
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We hope to create 
an engineering 
workstation with a 
cost-performance 
ratio lOO times better 
than that offered by 
general-purpose 
computers. 


Currently, our studies are being extended 
to problems relating to LSI design, such as 
the optimum allocation of logic devices and 
the routing among them. 

Summary. Reviewing the many applica¬ 
tions performed so far and being per¬ 
formed with PAX, we can summarize as 
follows: 

• Continuum models with the proximity 
property can be processed in parallel with 
high efficiency. 

• Particle models and linear-equation 
models with global data transfer can also be 
parallelized successfully. 

• Direct mapping of physical space to a 
PU array is easy to achieve and generally 
satisfactory, although degradation due to 
uneven work load may occur. 

• A general MIMD pipeline-processing 
operation can be carried out with conven¬ 
tional serial languages. 

• Even asynchronous MIMD-mode pro¬ 
cessing that involves transfer of irregular 
data (examples of applications that use such 
processing are LSI logic simulation and 
routing problems) can be made practical, 
since there is a speedup of O (P 1/2 ). 

• Those parallel algorithms with higher 
complexity than their serial counterparts 
(that is, inconsistent parallel algorithms), 
can be changed so that they are consistent, 
as in the case of the parallelization of the 
ADI scheme by the GECR method. This in¬ 
stance of parallelization can be extended to 
a general guiding principle for deriving the 
consistent algorithm: Carry out 

(1) intra-PU preprocessing with the 
complexity 0(S, (N/P )) by elimi¬ 
nating intra-PU variables to obtain 
reduced variables of the size 
0(/(P)), 


(2) inter-PU processing with the com¬ 
plexity O (g (P)) to solve the reduced 
variables, and 

(3) backward substitution with the 
complexity 0(S 2 (N/P )) to obtain 
the intra-PU variables eliminated 
in step 1. 

The symbols Sj, S 2 ,f and g are appro¬ 
priate functions; the complexity of serial 
processing of the same solution is expressed 
by 0(51 (AO +S 2 (N )). 

• For application problems with the larg¬ 
er N/P values—such as consistent cyclic re¬ 
duction by the GECR method, the norm 
(summation or maximum/minimum value) 
calculation by cascade algorithm, and the 
FFT—we can expect higher efficiencies. 

If the dimensionality of distributed data 
is higher than that of the PU array, and if 
any reduction in the size of data that are 
subject to trans-array move is made in each 
PU prior to the move (both conditions 
apply to cascade norm calculation), the 
trans-array move does not cause serious 
degradation of efficiency because the intra- 
PU calculation generally has a higher or an 
equal order of complexity than the move 
with respect to P. (Three- or four-dimen¬ 
sional continuum models mapped onto a 
two-dimensional PU array, and the solu¬ 
tion of linear equations by row-wise alloca¬ 
tion to a one-dimensional PU array are typ¬ 
ical examples falling into this category.) 

If there is no reduction of the size of data 
(as in the case of FFT, where all the data are 
subject to the butterfly move), serious de¬ 
gradation of efficiency occurs in a limit of 
infinite value of P. 

• Even in those less promising applica¬ 
tions with asymptotic degradation of ef¬ 
ficiency, there is an appreciable region of P 
in which we can expect reasonably high ef¬ 
ficiency from the technically feasible 
number of PUs and problem size. As a mat¬ 
ter of fact, we demonstrated in the actual 
measurements made so far on PAX that 
terms describing overhead have relatively 
small coefficients under the scaling law of 
parallel-execution time, hence overhead in¬ 
efficiency does not limit the number of pro¬ 
cessors that can be implemented in the near 
future. The viewpoint that a “nearest- 
neighbor connection array will not work 
due to data-transfer overhead” 16 is not 
correct in most of the representative ap¬ 
plication models, as evidenced by PAX. 

• From the viewpoint of users, the most 
striking difference between commercial 


supercomputers with a low degree of 
machine parallelism and this PAX-type 
highly parallel multiprocessor system exists 
in the PAX memory architecture. In the 
commercial supercomputer architecture, 
the memory is centralized and globally ac¬ 
cessible from all processors; in PAX ar¬ 
chitecture, memory devices are distributed. 
This makes it difficult to develop automatic 
software for PAX that can be used to parti¬ 
tion a job into parallel sub-tasks, map the 
partitioned tasks to PUs, and generate an 
object program for them. 

• At present, all the user application 
programs are written without automatic 
software, and parallelism is explicitly rep¬ 
resented—by users with conventional soft¬ 
ware tools for serial processing. Beginning 
users of PAX, however, who know only 
Fortran programming, manage to use PAX 
effectively after a training period of only 
one day to one month, depending on then- 
applications and level of expertise. 


T he target of PAX computer develop¬ 
ment is twofold: a super-fast machine 
with speed in the Gflops range, 
and an engineering workstation with a cost- 
performance ratio 100 times better than 
that offered by general-purpose computers. 

As concerns the first target: Even with 
contemporary LSI, we can construct a 
PAX machine with a speed of 1 Gflops by 
combining several hundred PUs that have a 
few Mflops speed. The final goal in this line 
is achieving a 1 Tflops machine with more 
than 10,000 PUs in the 1990’s. Naturally, 
many technological problems are antici¬ 
pated in extending the size of PU array to a 
number greater than 1000. We made a care¬ 
ful assessment of PAX 17 : Assuming con¬ 
temporary hardware technology, we found 
that the reliability limits the array size less 
than a few 1000 PUs. To get past this limita¬ 
tion, a redundant logic structure and an in¬ 
novative hardware-implementation meth¬ 
od have to be introduced. 

The other target—the attached processor 
that makes a minicomputer a very cost-ef¬ 
fective engineering workstation—is more 
realistic. The present PAX-64J realizes 6 
Mflops for $128,000—that is 50 flops per 
dollar. An even better performance-over¬ 
cost ratio—1000 flops per dollar—is emerg¬ 
ing with the use of CMOS technology. 
Though innovation in device technology 
contributes to all sorts of architectures. 
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CMOS technology warrants the highly 
parallel approach because of its high in¬ 
tegration, small heat dissipation, and low 
cost. 

The development of the special-purpose 
machine (SPM) is rationalized by cost ef¬ 
fectiveness to be realized. The repetition of 
SPM development in all representative 
fields might mean that the general-purpose 
machine (GPM) will eventually turn out to 
be one type of machine with a special fea¬ 
ture that it can use to cope with all kinds of 
problems. 

It is inadequate to discuss the develop¬ 
ment of software for the SPM in terms of 
that for the GPM. Though the SPM tends 
to lack software tools for general-purpose 
parallel processing, the system architecture 
of the SPM is designed to be close to the 
structure of application models, so the gap 
between users and machine is narrower 
than that for the GPM. Even the easiness of 
developing software is a merit of the SPM. 
Since PAX is a multiple-SPM, it follows the 
SPM’s approach to computer design, de¬ 
velopment, and utilization. 

We think that software and algorithmic 
problems have been solved well enough to 
start commercial hardware construction. 
Three-year development of a cost-effective 
PAX-type computer for scientific and engi¬ 
neering use started in 1984 under the spon¬ 
sorship of the Research Development 
Corp. of Japan. □ 
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Editor: Richard H. Thayer/Lockheed Software Technology Center/Austin, Texas 


P1003: A Unix standard for the rest of us 


by Jim Isaak 

Charles River Data Systems 

Over the last few years, the computing 
community has witnessed the spectacular 
success of standard operating systems. In 
the PC world, PC-DOS-compatible sys¬ 
tems have encouraged the rapid develop¬ 
ment of a wide range of applications 
software, and now for larger systems a 
similar process is taking place with Unix- 
compatible operating systems. Although, 
as with PC-DOS, much of the standard¬ 
ization process actually took place in a 
de facto manner in response to market 
forces, the IEEE Computer Society has 
also put substantial effort into develop¬ 
ment of a Unix-compatible standard that 
targets the goals of full application port¬ 
ability and vendor independence. Here 
we look at the history of the Unix- 
compatible effort, the nature of the Trial 
Use document that was recently ap¬ 
proved, the critical factors of compliance 
and specification, and the future direc¬ 
tion of the effort. 


The Trial Use document 

The work to define a standardized 
Unix-compatible systems environment 
began in 1981 with /usr/group, a Unix 
users’ group with a commercial orienta¬ 
tion. This effort resulted in the publica¬ 
tion of the 1984 /usr/group standard 
(see Table 1 for availability information). 
The question was then raised within the 
/usr/group organization of how this 
document could be raised to the ANSI 
and International Standards Organiza¬ 
tion level. Concurrently, the IEEE-CS 
Technical Committee on Operating Sys¬ 
tems received a Project Authorization 
Request (PAR) approval for PI003— 
“Operating System Kernel (Unix).” In 


1985 the two efforts merged under 
IEEE-CS governance, and in December 
the name was changed to P1003—“Stan¬ 
dard for Portable Operating System, for 
Computer Environments.” This more 
accurately reflects the nature of the doc¬ 
ument, and eliminates the trade name 
“UNIX” from the title. The Trial Use 
balloting on Draft 6 of this document 
was completed in December 1985, and in 
March 1986 it was approved by the IEEE 
Standards Board. It will be available late 
this spring as an IEEE Trial Use stan¬ 
dard and Draft ANSI standard. The 
document is proposed as a Trial Use 
document for a few reasons. It is com¬ 
plex, and will require more than a 30-day 
balloting period to get a comprehensive 
review. As proposed, it is not complete. 
There are definitions that “go without 
saying” in the Unix community but need 
clear specification for a standard, and we 
need feedback on these. And there are 
also some controversial issues that will 
benefit from feedback from a wider 
community before becoming part of a 
Full Use standard. The appendices 
outlining these issues and forms are pro¬ 
vided to encourage feedback. 

The stated purpose of PI003 is “to de¬ 
fine a standard operating system inter¬ 
face and environment based on the Unix 
operating system documentation to sup¬ 
port application portability at the source 
level.” It is intended for use by both^ys-- 
terns implementors and applications soft¬ 
ware developers. What is defined in 
Draft 6 are the C-language system calls 
that provide a wide range of operating 
system services. (Table 2 has a summary 
listing of these.) Since C is the native lan¬ 
guage of Unix-compatible systems, and 
most versions are implemented in C, this 


is an appropriate level of specification. 
This also creates a close tie between the 
PI003 effort and the American National 
Standards Committee (ANSC) X3J11 
C-language effort (see Table 1). We have 
had joint membership and the exchange 
of documents with the X3J11 group as a 
part of the coordination effort. A 
number of functions defined in the 1984 
/usr/group standard, including the stan¬ 
dard I/O libraries (STDIO), are defined 
in the “C Information Bulletin”—the 
draft X3JU document. To avoid the 
confusion of overlapping standards, 
these elements are specified as required 
in the P1003 document, but P1003 refers 
to the X3J11 document for definition. 
Since we would expect a larger range of 
implementations of the C-language than 
of the complete operating system en¬ 
vironment, this will maximize program 
portability. P1003 avoids any specifica¬ 
tion of implementation details. We 
believe that systems can conform to 
PI003 either as native-level implementa¬ 
tions or hosted on top of existing 
operating systems. 

In addition to the system interface 
functions, P1003 defines a data inter¬ 
change format. This describes how the 
various file and directory structures can 
be put into a flat format for transmission 
to a different system. This format is 
based on the TAR format used by many 
Unix-compatible systems for floppy disk 
and tape file interchange. While most of 
the system interface is carefully isolated 
from issues of character representation, 
bit ordering, and specific numeric values, 
the interchange format is very explicit. 

By specifying the exact values, notation, 
character set, byte ordering, and so 
forth, the interchange format becomes a 
common link between different con¬ 
figurations and systems. 

Some topics were excluded from 
P1003 to focus the effort on a deliver¬ 
able document. These include the 
specification of the interface to net¬ 
works, databases and/or record-oriented 
I/O, graphics interfaces, user-level (shell) 


The editor welcomes submissions from individuals or groups working on the 
development of computer standards. Send information to Richard H. Thayer, 
Technology Transfer, Lockheed Software Technology Center, 0/96-01, B/310, 
6800 Burleson Road, Austin, TX 78744; (512) 386-1486. 
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interfaces, and associated commands and 
object or binary code compatibility. 

Some of these areas will be addressed by 
related committee efforts. (See Table 3 
for a list of topics and committees.) 


Open issues 

A number of areas need to be ad¬ 
dressed by the working group to bring 
P1003 up to a Full Use level. Listed here 
are issues identified by the working 
group and/or the balloting group that 
need further work. 


Incomplete definitions. We have de¬ 
fined a number of key terms in the main 
document; however, an appendix lists 
definitions that are not quite solid, and 
still other terms may need to be defined 
for completeness’ sake. 


Terminal and device control function 
(ioctl and termio) definitions. Proposals 
here are listed in Appendix C of Draft 6 
for comment. This includes a fairly com¬ 
plete definition of terminal handling and 
two different device control routines that 
could be used for terminals and other 
devices. The draft identifies the areas of 
concern about the differing proposals. 


Internationalization. While P1003 has 
tried to address some of the most ob¬ 
vious issues of international use, we are 
not convinced that all have been ad¬ 
dressed. Here a much broader review is 
needed than can be brought together in 
the working group. The April working 
group meeting was held in Florence, 
Italy, just prior to the European Unix 
Users Group meeting, for the purpose of 
increasing international participation. 


Record and file locking mechanisms. 

The 1984 /usr/group document defines 
an advisory and enforcement mode of 
locking access to files. This concept is 
consistent with the byte-stream orienta¬ 
tion of the file system, and uses a file 
position with a variable number of bytes 
as the object locked. Draft 6 of P1003 
includes the advisory mode as part of the 
main document; the enforcement mode 
is included in Appendix E (appendices 
are not part of the standard). A sub¬ 
group has been formed to determine the 
range of objectives these mechanisms 
satisfy, and to answer some of the more 
serious questions about their use. 


Vendor compliance and 
user specification 

Two advantages to publishing a Trial 
Use document are that (1) vendors get a 
chance to determine how well they can 
comply with a proposed standard and (2) 
buyers get the opportunity to specify 
compliance with it. Both government 
and industry, for example, have ex¬ 
pressed great interest in purchasing Unix- 
compatible systems. This is an essential 
part of the chicken-and-egg problem of 
getting the three elements of an effective 
standard in place: consensus definition; 
vendor implementation; and user specifi¬ 
cation. A standard is useful only in pro¬ 
portion to these three factors. We need 
to migrate the specification of Unix- 
compatible systems from implementa¬ 
tion-specific terminology such as 
“Xenix,” “UNOS,” “UNIX System 
V,” and “Berkeley 4.2” to standards 
conformance: “Operating system must 
conform to the IEEE P1003 standard for 
Portable Operating System for Com¬ 
puter Environments.” This may not be a 
complete definition of the facilities re¬ 
quired, so additional specifications can 
be added. Areas where this may be ap¬ 
propriate include network and database 
facilities; shell and tool facilities; and 
specific extensions such as those for real¬ 
time operations. (See Table 3 for infor¬ 
mation about related standards.) Similar¬ 
ly, it is possible to specify applications as 
“Conforming Applications” with P1003, 
or as “Conforming Portable Applica¬ 
tions” with P1003. The key difference is 
the potential use of system extensions: a 
Conforming Portable program cannot 
use them, whereas a Conforming pro¬ 
gram must document them. In addition 
to the conformance terminology, Draft 6 
contains two tables of information useful 
for specifying and comparing implemen¬ 
tations. The first is the “limits.h” table 
that indicates various values that applica¬ 
tions may need to use at execution time. 
These include the number of bits in a 
character, the maximum length of a file 
name, and so forth. The second table is 
in Appendix H. This tends to relate to 
characteristics that reflect the nature of 
the hardware/operating system environ¬ 
ment in a static sense, which may reflect 
limits on applicability of a system. In¬ 
cluded in this list are the maximum 
number of users, maximum address 
space, maximum file size, etc. 

The topics that are currently under 
consideration or that will soon come 
before the group include real-time exten¬ 
sions, the shell-level interface, and net¬ 
working interfaces. In the real-time area, 
we have a mature proposal for high- 
performance files. Other topics of in- 

(continued on p. 84) 


Table 1. Standards documents and where 
to get them. 

1984 /usr/group standard: 

/usr/group 

4655 Old Ironsides Drive, Suite 200 
Santa Clara, CA 95050 

"C Information Bulletin" (X3J11): 

X3 Secretariat 
CBEMA 

311 First St. NW, Suite 500 
Washington, DC 20001 

IEEE PI 003.1 Trial Use standard (document 
# SH10546): 

IEEE Service Center 
445 Hoes Lane 
Piscataway, NJ 08854 
(201) 981-1393 


Table 2. Draft 6 functions overview. 


Process primitives: 
Process environment: 
File system: 
Input/output: 

Device functions: 

C language library 

Passwords 

Data interchange: 


fork, exec, signal, 
delay. 

ID, groups, time, terminal 
ID. . . . 

directories, links, FIFOs, 
characteristics 
open/dose/read/write, 
seek, lock, control 
spot for ioctl and termio 
reference to X3J11 and 
fileno, fdopen 
encoding, read, access, 
and control 
TAR format 


Table 3. Related standards. 

Networking 

IEEE 802.x series for ISO layers 1 and 2 

!S0 standards (request list for networking): 

ISO TC97/SC6 Secretariat 

ANSI (American National Standards Institute) 

1430 Broadway 

New York, NY 10018 

US Government Federal Information Processing 
Standards (FIPS); FIPS 107 is for Local Area 
Nets: 

NTIS 

US Department of Commerce 
5285 Port Royal Road 
Springfield, VA 22161 


X3H2 (SQL) and X3H4 (IRDS): 

CBEMA X3 Secretariat (see Table 1) 


May 1986 




UPDATE 


Board of Governors meets at 21st Compcon Spring 


On March 7 the IEEE Computer 
Society Board of Governors held its first 
meeting of the year in San Francisco, 
California, at the close of Compcon 
Spring ’86. This year marked the 21st 
anniversary of the Computer Society- 
sponsored conference. Chaired by Glen 
G. Langdon, Jr., the conference covered 
such topics as reliability of software for 
the Strategic Defense Initiative, artificial 
intelligence applications, trends in super¬ 
computers, and Japanese software 
practices. 

New Board members elected. The 

Board of Governors elected Computer 
Editor-in-Chief Michael C. Mulder to fill 
a vacancy on the board created by a 
resignation. Mulder will serve through 


1986. Oscar N. Garcia, president of the 
Computer Society from 1981 to 1983, 
was elected to membership-at-large as a 
nonvoting, ex-officio member of the 
board. Garcia serves as chair of the 
Intersociety Cooperation Committee and 
as the society’s representative to ACM. 

Officers confirmed. The Board of 
Governors confirmed President Roy 
Russo’s appointment of vice presidents 
and the treasurer for 1986. The members 
of the 1986 Executive Committee of the 
Computer Society, including elected, ap¬ 
pointed, and ex-officio members, are as 
follows: 

Roy L. Russo, President 
J.T. Cain, Vice President for Publica¬ 
tions (First VP) 


John D. Musa, Vice President for 
Technical Activities (Second VP) 
James H. Aylor, Vice President for Con¬ 
ferences and Tutorials 
Glen G. Langdon, Jr., Vice President for 
Educational Activities 
Ming T. Liu, Vice President for Member¬ 
ship and Information 
H. Troy Nagle, Jr., Vice President for 
Area Activities 

Helen M. Wood, Vice President for 
Standards 

Fletcher J. Buckley, Secretary 
Joseph E. Urban, Treasurer 
Ronald G. Hoelzeman, IEEE Division 8 
Director 

Martha Sloan, Junior Past President; 

IEEE Division 5 Director 
T. Michael Elliott, Executive Director 

New PAMIEIC appointed. The 

Board of Governers also consented to 
the president’s appointment of Steven 
Tanimoto of the University of Washing¬ 
ton as the new Editor-In-Chief of IEEE 
Transactions on Pattern Analysis and 
Machine Intelligence (PAMI) , as 
recommended by the Publications 
Board. 

Computer Pioneer Award winners for 
1986. Acting on the recommendation of 
the Awards Committee, chaired by 
Ralph Preiss, the board named the 
following individuals as 1986 Computer 
Pioneer Award recipients: 

Cuthbert C. Hurd, for contributions 
to early computing; 

Peter Nauer, for contributions to 
computer language development; 

James Pomerene, for early work on 
the IAS and Harvest computers; and 
Adriaan von Wijngaarden, for 
ALGOL68. 

Bylaws changes. Approved for the sec¬ 
ond and final time were bylaws changes 
that implement the constitutional 
amendment approved by the member¬ 
ship last fall. These changes established 
the position of president-elect. The first 
individual to hold this position will be 
elected by the membership in Fall 1986. 

In addition, the Board of Governors 
approved a bylaws change that would 
add the Computer Society elected 
delegate directors to the IEEE Board of 
Directors as ex-officio, nonvoting 
members of the board. According to 


Board of Governors approves bylaws changes 


At its March 7 meeting in San Fran¬ 
cisco, California, the Computer Society 
Board of Governors gave first approval to 
the following changes to the constitution 
and bylaws of the IEEE Computer Socie¬ 
ty. The effect of the changes is to clarify 
the definition of a majority vote at 
meetings of the Computer Society Board 
of Governors and Executive Committee 
and to permit IEEE Delegate Directors 
from the IEEE Computer Society to hold 
ex-officio posts on the Computer Society 
Board of Governors. 

The amendments are published here 
for comment by the membership prior to 
final Governing Board consideration at 
its June 19 meeting. Comments should 
be sent to 
Roy L. Russo 

IBM T.J. Watson Research Center 
Route 134 
PO Box 218 

Yorktown Heights, NY 10598 
Compmail-i- R.RUSSO 

In the text below, deletions to original 
wording are enclosed in brackets [ ]; addi¬ 
tions appear in italics. 


IEEE Computer Society 
Constitution 


Article III 

Section 6: The presence of a majority of 
the franchised Board members shall con¬ 


stitute a quorum. Proxies shall not be 
used to constitute a quorum. When a 
quorum is present at a meeting, a majori¬ 
ty vote [of the franchised Board members 
present] shall be necessary for the con¬ 
duct of business except as otherwise 
provided in the Society’s constitution 
and bylaws. 


IEEE Computer Society 
Bylaws 


Article III 

Section 11: Delegate Directors 

The IEEE Delegate Directors from the 
Computer Society shall be ex-officio 
members of the Board, without vote, 
unless holding a vote as a franchised 
Board member. 


Article IV 

Section 4: Quorum 

A quorum shall consist of a majority of 
the Executive Committee members. A 
majority vote [of those Executive Com¬ 
mittee members present] is required to 
transact business. Proxies shall not be 
allowed. 
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society bylaws, this amendment must be 
published for comment by the member¬ 
ship in Computer magazine (see accom¬ 
panying sidebar) and approved a second 
time by the board at its subsequent 
meeting. 

Support for research. The board passed 
a resolution endorsing the need for addi¬ 
tional individual research grants in com¬ 
puter science and engineering as advo¬ 
cated by the Computer Science Board. 
The Computer Science Board was re¬ 
quested, however, to add data on com¬ 
puter engineering research to that pro¬ 
vided on computer science research in its 
report on the subject. 

Member participation in elections. 

Noting the relatively low participation 
rate of the membership in the Computer 
Society Board of Governors and officer 
elections, the board charged the Elec¬ 
tions Committee with identifying 
changes in method of election that might 
encourage greater member participation. 
The Elections Committee is chaired by 
Wing Toy. 

In other actions, the Computer Society 
Board of Governors voted 

• not to participate in future Space 
Technology conferences; 

• to endorse the AFIPS project en¬ 
titled “Technology in Education” (TIE), 



Computer Editor-in-Chief Michael C. 
Mulder was elected to the Computer 
Society Board of Governors March 7. 


which joins computer professionals with 
secondary school teachers to improve ed¬ 
ucation; and, 

• to approve revisions of the editorial 
page budgets of the magazines that re¬ 
flect the effects of a change in type den¬ 
sity implemented to reduce costs. No re¬ 
duction of technical content results from 
these changes. 

Future meetings. Additional 1986 
meetings of the Board of Governors are 



Steven Tanimoto of the University of 
Washington has been appointed Editor- 
in-Chief of IEEE Transactions on Pattern 
Analysis and Machine Intelligence. 


planned for the following dates: 

May 9—Miami, Florida 

June 20—Las Vegas, Nevada (NCC) 

November 7—Dallas, Texas (FJCC) 

The board also adopted a schedule of 

meeting dates for 1987 as follows: 

February 27—Compcon Spring, San 

Francisco 

May 8—location to be determined 
June 19—NCC, Las Vegas, Nevada 
October 30—FJCC, Dallas, Texas 


Program chair states objectives for CS data engineering conference 


Since the Computer Society held its 
second data engineering conference last 
February, Gio Wiederhold of Stanford 
University, 1986 program chair, has sum¬ 
marized the objectives and procedures of 
the conference for other members of the 
society. His remarks appear in con¬ 
densed form below. Comments or sug¬ 
gestions can be addressed to Wiederhold 
on Compmail + at G.WIEDERHOLD. 

The main objective of the conference 
is to present significant, high-quality in¬ 
formation to a balanced audience of aca¬ 
demic and nonacademic people. The 
conference should serve as a two-way 
link between industry and academia to 
the benefit of both. In this context, data 
engineering complements program engi¬ 
neering, concentrating on semantics and 
structuring of data. 

Papers cover traditional and novel 
topics. Major areas of past interest in¬ 
clude data modeling, concurrency con¬ 
trol, and distributed systems. We need 
more mapping of models to physical im¬ 
plementations in the future, addressing 
fundamental issues of physical design 
and performance. Nontraditional areas 


of interest include heterogeneous and 
multimedia databases, knowledge base 
systems, fuzzy systems, and temporal 
databases, even AI concepts. 

A cadre of volunteers organizes the 
conference. With the authors, they form 
the organizing committee. Because the 
society wants continuity and innovation 
within the conference, we have intro¬ 
duced some circulation within the orga¬ 
nizing committee. For similar reasons, 
the program committee chair is selected 
from the prior year’s program commit¬ 
tee. In the year following, the program 
committee chairperson becomes the gen¬ 
eral chair, while the general chair be¬ 
comes the honorary chair and joins the 
steering committee. All of these people 
together participate in the refereeing pro¬ 
cess for papers and in award recom¬ 
mendations. 

An experimental concept is that of dis¬ 
cussion sessions devoted to papers on 
one topic. The concept of the discussion 
session arose out of a recognition of 
problems inherent in the formats of both 
conference panel sessions and regular 
paper sessions. Panel sessions are gener¬ 
ally popular, but disappointing when 


speakers are not adequately prepared. 
Authors presenting their work in paper 
sessions are usually well-prepared, but 
often find it hard to summarize the 
results of years of effort on a problem in 
a short time. In a discussion session, 
authors present their papers in an ab¬ 
stract format, briefly stating the prob¬ 
lem, a summary of the work, and the 
conclusions. The discussion chair makes 
notes during the talk and later leads a 
discussion of the issues that the author 
has raised. The interplay of ideas be¬ 
tween discussion chair, authors, and au¬ 
dience is intended to help clarify the 
issues. 

The general conference format in¬ 
cludes discussion sessions, traditional 
paper sessions, a plenary session each 
day to tie everyone together, and a gen¬ 
eral reception in the evening. Tutorials 
on the days before and after the con¬ 
ference provide other ways to get up to 
speed. 

The society welcomes any other sug¬ 
gestions to make participation in the 
data engineering conference more 
valuable. 
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First Asia Pacific Area Meeting of IEEE CS held in Hong 
Kong 


The First Asia Pacific Area Meeting of 
the IEEE Computer Society was held 
Aug. 26-27, 1985 at Hotel Plaza, Hong 
Kong. The major objective was to dis¬ 
cuss how the Computer Society could 
promote regional cooperation in devel¬ 
opment of information technology appli¬ 
cations. Delegates came from Australia, 
Hong Kong, India, Indonesia, Japan, 
Korea, Malaysia, New Zealand, Pakis¬ 
tan, the Philippines, Singapore, Sri 
Lanka, and Thailand. Anthony Pau, 
elected area chair of the Asia Pacific Re¬ 
gion, chaired the meeting. 

Delegates agreed to form a Regional 
Cooperation Committee for IEEE CS 
Region 10. Task groups under its control 
will cover structure (Philip McCrea), lan¬ 
guage (Luis Alarilla, Jr.), computer com¬ 


munications (Joseph Luhukay), libraries 
(N.V. Balasubramanian), training 
(Leung Kuo-sing), establishment of a 
data bank (P.K. Patwardhan), tech¬ 
nology transfer (Abdul Rahman Abdul¬ 
lah), and industrial liaison (Osamu Ishii). 
The delegates also agreed to set up dis¬ 
counted membership fees (V. Techadam- 
rongsin) for those countries with a low 
income level. A newsletter (Robin Har¬ 
rington) is planned to facilitate commu¬ 
nications among member countries. 

Delegates decided to adopt English as 
the official language for exchange of 
technical information in the Asia/Pacific 
region. They also agreed to urge the 
IEEE Computer Society Governing 
Board to lend its strongest support to 
Region 10 because of the region’s tre¬ 
mendous potential for growth. 



The First Asia Pacific Area meeting of the IEEE Computer Society, held August 26-27, 
1985 in Hong Kong drew representatives from throughout Region 10. 


Pittsburgh to get national supercomputing center 


The National Science Foundation has 
announced a grant of nearly $40 million 
to the Mellon-Pitt-Carnegie Corpora¬ 
tion, a partnership of the University of 
Pittsburgh and Carnegie-Mellon Univer¬ 
sity, to establish a national supercomput¬ 
ing center in Pittsburgh. 

The center will purchase a $22 million 
Cray X-MP/48 supercomputer and other 
related equipment, for a total project 
value of over $70 million. 

To be known as the Pittsburgh Center 
for Advanced Computing in Engineering 
and the Sciences, the center will be 
operated by a consortium of CMU, the 
University of Pittsburgh, and the West- 
inghouse Electric Corporation. Other 


supporters include Cray Research, Inc. 
The Pennsylvania state legislature is con¬ 
sidering a $5.25 million appropriation 
for the first three years of the center’s 
operation as part of a regional develop¬ 
ment plan. 

The University of Pittsburgh joins 
Cornell University, Princeton University, 
the University of Illinois, and the Uni¬ 
versity of California at San Diego in the 
ranks of supercomputing centers estab¬ 
lished by the NSF. All five centers will be 
linked together by an NSF network. Re¬ 
searchers will be able to access the net¬ 
work at the nearest supercomputing site 
and communicate with any of the other 
supercomputers. 
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terest here include shared data, inter¬ 
process communications, and priority 
scheduling. The shell-level interface will 
deal with facilities needed to port ap¬ 
plications, as well as those that are useful 
during execution as services of the 
system at the application level. The net¬ 
working will stay a distance from the 
controversies of cables and protocols, 
and will focus instead on the C-language 
interface to key layers in the ISO model. 
Here we would expect to see an interface 
defined at the ISO session level and 
perhaps various applications layer 
facilities such as File Transfer (FTAM) 
and/or electronic mail. 

If you are interested in becoming a 
correspondent, active working group 
member, or balloting group member, 
send your name, address, phone num¬ 
ber, uucp address (if any), and IEEE/CS 
affiliate number (if any) to the IEEE 
Standards Office, 345 E. 47th St., New 
York, NY 10017, indicating your interest 
in the P1003 effort and the type of par¬ 
ticipation you desire (correspondent, 
working group, sub-group and/or ballot¬ 
ing group). Meetings are held every three 
months; the next meeting will be held in 
June in Atlanta, Georgia. 


Jim Isaak is the director of strategic market¬ 
ing for Charles River Data Systems. He has 
been active in directing the product strategies 
for the Charles River Universe family of 
supermicro computer systems, including the 
real-time Unix environment, ISO/MAP— 
TOP networking, and distributed processing 
environments. Isaak is also the chairperson of 
the IEEE P1003 working group. He has been 
involved with systems work at Data General, 
Intel, Calma and IBM over the last 16 years. 

Isaak’s educational background includes an 
MSEE degree from Stanford. He is a member 
of the IEEE, the IEEE Computer Society, 
and the ACM. 

Readers may write to the author at Charles 
River Data Systems, 983 Concord St., Fram¬ 
ingham, MA 01701. Electronic mail ad¬ 
dresses—uucp: decvaxifrogijim; COMP- 
MAIL+J.ISAAK. 
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THE WORKSTATION 


GWW: A structured environment for building natural language interfaces 



Figure 1. A recursive transition network used for parsing natural language. An input is 
acceptable if it can be used to traverse the “S” network and also satisfy any tests 
which may be associated with its arcs. Some arcs require the traversal of other net¬ 
works. 


by Jeff Pepper, Robert L. Joseph, and 
Philip J. Hayes 
Carnegie Group, Inc. 

A team at Carnegie Group, Inc. has 
recently completed work on Grammar 
Writer’s Workbench (GWW), a devel¬ 
opment environment used to build 
natural language interfaces to computer 
programs. This work has given us the 
opportunity to apply some of the prin¬ 
ciples of structured software devel¬ 
opment environments, including text- 
format structure editors, to the novel 
domain of grammar writing. This article 
discusses the domain of natural language 
interfaces, our experience in building the 
Grammar Writer’s Workbench, and the 
implications this work may have for 
building development environments in 
other domains. 


Language Craft 

Language Craft 1 is the culmination of 
several years of effort at Carnegie Group 
to build a tool for creating robust natu¬ 
ral language interfaces to application 
programs. Historically, software devel¬ 
opers have been interested in the pros¬ 
pect of using natural languages like 
English to interface with their programs, 
especially in database inquiry systems, 
factory and office automation, and ex¬ 
pert systems. Unfortunately, wide use of 
natural languages has been hindered by 
the “brittleness” of the software. Exist¬ 
ing natural language interfaces often per¬ 
form well when presented with complete, 
grammatically correct sentences, but fail 
completely when given input that devi¬ 
ates even slightly from the expected form 
(e.g., unusual sentence structure, errors 
in syntax or spelling, partial sentences, or 
unrecognized words). 

Traditional natural language systems 
are based on the concept of network 
parsing, 2 where sentence structure and 
meaning is compiled into a network of 
nodes and directed arcs (see Figure 1). 
Nodes in the network represent words or 
phrases, and arcs represent legal transi¬ 
tions from one node to another. These 
arcs are sometimes augmented with addi¬ 
tional information about sentence struc¬ 


ture and meaning. Using the network ap¬ 
proach, an input sentence is considered 
correct, and can be successfully pro¬ 
cessed, if it can be matched to a path 
through the network. 

Recent work 3 ’ 4 has resulted in a 
radically different approach to natural 
language processing using caseframe 
grammars to define the language in 
which users of the application program 
can be expected to communicate. A 
caseframe grammar represents language 
at a higher level of abstraction than a 
simple network, just as a textbook on 
cooking represents the process of cook¬ 
ing at a higher and more meaningful 
level than a book of recipes. A natural 
language interface uses caseframes to 
recognize the “gist” or primary meaning 
of the input first, then uses this under¬ 
standing of the sentence’s probable 
meaning to guide its parsing, or analysis. 
Because information about the sequence 
of words and phrases is implicit rather 


than explicit, caseframe-based interfaces 
are generally much more robust than 
network-based interfaces. Caseframe 
grammars are very good at handling dif¬ 
ficult inputs such as grammar errors, 
misspelled words, and ellipses (fragmen¬ 
tary sentences). 

Caseframes are the basic building 
blocks of a caseframe grammar. A gram¬ 
mar contains one caseframe for each ma¬ 
jor concept to which an input can be 
matched. Each caseframe consists of a 
name, a number of slots and values that 
pertain to the entire caseframe, and a 
variable number of cases, each of which 
also contains slots and values. Figure 2 
shows part of a typical caseframe, taken 
from a factory management caseframe 
grammar. This caseframe represents the 
concept of “movement,” and is trig¬ 
gered by the appearance of any form of 
the verbs “move,” “transfer,” or 
“shift” in an input. The three cases in- 


The Workstation is a forum for short articles on current research and 
developments in the computing sciences from industry, universities, and 
government. Submit articles of between 1000-3000 words in length to 

Michael C. Mulder, Director, Applied Research, University of Portland, 
Portland, OR 97203. 
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[‘move* 

:type sentential 

:header move | transfer | shift... 

:cases 
(work-order 
rfiller *work-order* 
positional direct-object) 

(destination 
:filler ‘position* 

:case-marker to into ...) 

(start 

:filler ‘position* 

:case-marker from out of ...)...] 


Figure 2. Part of a typical caseframe. 


dicate that the caseframe expects, but 
does not require, the input to contain a 
work-order phrase which is the object of 
the sentence, a destination phrase begin¬ 
ning with “to” or “into,” and a start 
phrase beginning with “from” or “out 
of. ’ ’ This caseframe can recognize input 
such as “Move work order #577 from 
the stockroom to Machine X,” or “Was 
this work order moved from Machine Y 
to Machine Z?” It can then process the 
input and pass the extracted information 
on to the application program for fur¬ 
ther processing. 

In addition to caseframes, a caseframe 
grammar has several other components. 
These contain rules which further define 
the grammar, such as rules for handling 
abbreviations and irregular verb forms, 
and rules which define the grammar’s in¬ 
terface with the application program. 
Thus, a grammar is a highly structured 
text document, much like a computer 
program. 

As we developed the Language Craft 
product, we recognized that the task of 
writing a grammar bore a striking 
resemblance to computer programming, 
and that grammar writers would benefit 
from the same sort of structure editors 
and specialized development environ¬ 
ments that already existed for program¬ 
mers. This led to the concept of a 
workbench which would aid grammar 
writers in creating a caseframe grammar, 
editing the grammar within guidelines 
provided by the workbench, and testing 
the syntactic portions of the grammar 
without having to go through the tedious 
edit-load-compile cycle familiar to any 
programmer. 


The Grammar Writer's 
Workbench 

The result of this development is 
GWW, the Grammar Writer’s Work¬ 
bench. GWW is a multiwindow environ¬ 


ment for creating, modifying and testing 
caseframe grammars. A typical display is 
shown in Figure 3. The user has access to 
an editor window for editing the con¬ 
tents of a grammar, a tryout window for 
submitting test inputs to the parser, a 
trace window for tracing the parsing pro¬ 
cess, application windows for providing 
direct access to other programs such as a 
user’s application or the operating sys¬ 
tem, a tree window showing the parse 
trees resulting from the parser’s attempt 
to analyze the sample input, and a com¬ 
mand window for issuing top-level com¬ 
mands to Language Craft. 

The system developer can specify the 
number, size, and placement of windows 
by using interactive commands or a con¬ 
figuration file. Thus, he can construct 
different configurations depending on 
whether he is in the initial stages of de¬ 
velopment, in later debugging stages, or 
in an actual field-test of the final system. 
In this last case, the workbench can be 
configured so that the application win¬ 
dows are suppressed, making the work- 

invoked by the end user. 

A key feature of GWW is its use of an 
integrated internal data structure. The 
grammar editor program uses a data 


structure which is virtually identical to 
that used by the parser. This allows the 
editor to provide many of the features of 
the parser, such as checking for syntactic 
errors (unbalanced parentheses and mis¬ 
spelled keywords), superficial grammar 
errors (two caseframes with the same 
name, or referring to a nonexistent 
caseframe), and more subtle errors 
(logical inconsistencies between case slot 
values and other case or caseframe slot 
values). A possible future enhancement 
would be for the editor and parser to 
share the same internal data structure, 
allowing the results of grammar editing 
to be immediately reflected in the be¬ 
havior of the parser. Currently, this is 
accomplished indirectly, through a com¬ 
mand which loads the current version of 
the grammar into the parser. 


GWW is device-independent, and can 
run on any machine that provides a full 
implementation of the Common Lisp 



Lisp workstations, as well as the DEC 
VAX family of computers. 



























GED 

GED is the grammar editor of GWW. 
It is a structure editor, meaning that it 
has an internal representation of the 
structure of its domain (caseframe gram¬ 
mars), which it uses to guide the editing 
process. GED provides templates for 
creating grammar items, checks those 
items for syntactic correctness, and pro¬ 
vides a measure of semantic error check¬ 
ing as well. 

GED presents a grammar hierarchical¬ 
ly with four levels of abstraction, as 
shown in Figure 4. The top-level view 
provides a one-line summary of each 
major grammar component, enabling the 
user to view the entire grammar in sum¬ 
mary form and then select the compo¬ 
nent that he wants to edit. The second 
level provides a detailed view of any 
component except the caseframes, since 
these components are structurally quite 
simple. However, the second level for 
caseframes gives a different view (one 
summary line per caseframe), enabling 
the user to add, delete or rename entire 
caseframes or select one for further 
editing. The third and fourth levels exist 
for caseframes only. The third level 
displays an entire caseframe but in con¬ 
densed form, showing only those slots 
which have already been edited and 
given values. By toggling the “invisible” 
mode of the editor, the user can pene¬ 
trate to the fourth level where all slots of 
the caseframe are visible and accessible 
for editing. 

A major design goal for GED was to 
give the user the freedom of an unre¬ 
stricted full-screen text editor while at the 
same time preventing syntax errors and 
eliminating the need for tedious typing. 
We accomplished this by modeling the 
user interface after the Emacs text 
editor, 5 enabling the user to add, delete, 
and edit text using familiar text editor 
commands. In some cases the meaning 
of commands was altered slightly to take 
advantage of the structure inherent in the 


grammar (for example, control-N means 
“move down one line” in Emacs, but 
means “move down one grammar item” 
in GED). New commands were added 
for GED-specific actions, such as 
creating new grammar items and moving 
up and down in the grammar hierarchy. 

We felt that error checking at each 
keystroke was undesirable for two 
reasons. First, the computational over¬ 
head was too high. Second, we felt that 
it would have placed too much restric¬ 
tion on the user’s text editing freedom, 
since the program would have recognized 
an error even if the user knowingly typed 
it and intended to fix it later. GED does 
not check for errors until the user is ac¬ 


tually finished working on a grammar 
item (signaled either by moving the cur¬ 
sor to another item, or by exiting to 
another level in the hierarchy). GED 
then performs extensive checks on the 
item. 

The grammar editor prevents users 
from making most punctuation and syn¬ 
tax errors by automatically providing the 
essential structure of the grammar and 
protecting that structure from editing. 

As an illustration, consider the process 
of creating a rewrite rule, an item within 
a grammar which is used to define 
synonyms. A typical rewrite rule such as 

< direction > — (North | East | South | West) 



Single caseframe,condensed 


Single caseframe, detail 
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permits a grammar writer to use the sym¬ 
bol “ < direction > ” in a caseframe to 
stand for any of the four words 
“north,” “east,” “south,” or “west.” 
To create a rewrite rule, the grammar 
writer presses control-O to get a basic 
skeleton for a rewrite rule: 

<> -0 

The cursor is initially positioned between 
the “ < ” and “ > ” characters. The 
grammar writer can then type in the 
word “direction” on the left-hand side 
of the rewrite rule, or edit the contents 
of the right-hand side by moving the cur¬ 
sor one position to the right, to the space 
between the “(” and “)” characters, 
jumping over the intervening protected 
characters. The grammar writer is unable 
to alter the punctuation of the rewrite 
rule or to move the cursor to a place 
where input would be meaningless or il¬ 
legal. When the cursor is moved out of 
the rewrite rule, GED performs its error 
checking. 

Comments are important in any struc¬ 
tured document, and GED provides an 
easy-to-use method of automatic com¬ 
ment placement. The user may type a 
semicolon at any time during an editing 
session, causing GED to automatically 
open up a blank line in what it considers 
to be the appropriate place in the gram¬ 
mar. It inserts a comment delimiter, 
positions the cursor just past the delim¬ 
iter, and waits for the user to type the 
text of the comment. The user can add 
more comment lines by typing more 
semicolons. GED places the comment 
based on the structure of the grammar 
and the position of the cursor within that 
structure. Users may associate comments 
with individual caseframes or other rules, 
or embed comments in particular cases 
within the caseframes. GED also en¬ 
forces standards for the indentation and 
placement of comments, making the 
resulting grammars easy to read. 


Conclusions 

We feel that the Grammar Writer’s 
Workbench as a whole succeeded in pro¬ 
viding a flexible and user-friendly 
environment for building caseframe 
grammars. GED was more of a mixed 
experience, but we learned a great deal 
about the power and limitations of this 
approach to structure editors in the 
process of building the program. 

Not surprisingly, we discovered that 
expert users were unwilling to give up 
their favorite text editors and switch to 
the structured grammar editor. Expert 
users are far less willing than novices to 
put up with restrictions in an editor, and 
will only tolerate structure if it will save 


them keystrokes. If it interferes with 
their development work they will aban¬ 
don the structured tool and simply use a 
free-format text editor. To accommodate 
these users, we made GED’s interface as 
similar as possible to a free-format text 
editor, and also provided “free features” 
like error checking and file-format 
compatibility with regular editors. This 
last feature proved to be more difficult 
than we had expected, since the editor 
had to be able to read a text-format 
grammar into GED’s internal data 
representation (preserving embedded 
comments), and then convert it back to 
original text format again without 
making any significant changes in the 
layout of the grammar text and 
comments. It was well worth the effort, 
though, because most experts would only 
use GED if they knew they could go 
back to their text editor whenever they 
wanted. 

Novice users, on the other hand, 
welcomed the structure provided by the 
editor, since it prevented them from 
making most syntactic errors and gave 
them a framework for building their 
grammars. 

There is still a great deal we can do to 
extend the capabilities of the Workbench 
and the editor. Possible enhancements 
include (1) fully integrating the grammar 
editor with the parser, to eliminate the 
need to explicitly tell the parser when the 
grammar file has been modified; (2) 
extending GED’s editing capabilities to 
provide more of the features of free- 
format text editors, such as global search 
and replace; (3) improving performance 
to provide rapid response during editing; 
and (4) providing checks for more subtle 
semantic errors, taking advantage of the 
editor’s structured data representation. 
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NEW PRODUCTS 


Editor: Demitrios Michalopoulos/California State University, Fullerton 


Personal workstations from Apollo 


Apollo Computer Inc. has introduced 
the Domain Series 3000 Personal Work¬ 
stations in high-resolution color and 
monochrome versions. The workstations 
combine an IBM PC-AT-compatible bus 
with the 32-bit Motorola MC68020 pro¬ 
cessor and MC68881 floating-point 
coprocessor. The company plans to offer 
a PC coprocessor option, now under 
joint development with Phoenix Soft¬ 
ware Associates, Ltd., that will let Series 
3000 users run PC programs in a display 
window while running technical applica¬ 
tions in windows under the Domain en¬ 
vironment. 

The color personal workstation 
features a 15-inch, 60-Hz color monitor 
with 1024-by-800 resolution; simultane¬ 
ous display of 16 colors from a palette of 
4096 colors; 2 or 4M bytes of memory; 
network interface; Domain/IX (Unix 
System V and Berkeley 4.2) and Aegis 
software licenses; keyboard and mouse; 
and a variety of options. Prices start at 
$14,900. 

The monochrome personal worksta¬ 
tions includes the same features but with 
a 19-inch, 64-Hz monochrome monitor 
with 1280-by-1024 resolution. Prices start 
at $9900. 

The Series 3000 PC-AT-compatible 
bus works with PC options such as 


printers, scanners, telephone systems, 
and so forth. 

Two graphics workstations, the 
DN570 and DN580, are compatible with 
the Series 3000 Personal Workstations 
for data sharing and two- and three- 
dimensional graphics. The DN580 im¬ 
plements virtual memory graphics 
technology, according to the company, 
and costs $43,900. The DN570 with a 
15-inch monitor starts at $29,900; with a 
19-inch monitor, $32,900. 

Also available are the DSP9000 com¬ 
pute server and the DSP3000 peripherals 
server ($15,500). According to Apollo, 
the DSP9000 achieves up to 94 Mflops 
and 35 MIPS. The DSP9000 servers are 
based on the FX minisupercomputers 
from Alliant Computer Systems Corp. 
They support such applications as 
ANSYS, Abacus, and SPICE, and auto¬ 
matically run existing ANSI Fortran 77 
programs. The DSP9011 configuration 
has one computational element (CE) and 
delivers up to 11.8 Mflops and 4.5 
MIPS, according to Apollo. Prices start 
at $195,750. The DSP9081, expandable 
to eight CEs, reportedly reaches 94 
Mflops and 35 MIPS. Prices start at 
$325,250 for one CE and range up to $1 
million for a configuration with eight 
CEs. All DSP9000 configurations inter¬ 
face with the Domain network. 



The Apollo Domain Series 3000 Personal 
Workstations come in color and mono¬ 
chrome versions. 


For more information on these prod¬ 
ucts, contact Apollo Computer Inc., 330 
Billerica Rd„ Chelmsford, MA 01824; 
(617) 256-6600. 
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Compaq portable gets smaller 


Compaq Computer Corp. has in¬ 
troduced the Compaq Portable II. Ac¬ 
cording to the company, the three new 
models are 30 percent smaller, 17 percent 
lighter, and 400 percent faster than the 
8088-based Compaq Portable and Com¬ 
paq Plus. 

The Portable II incorporates the 80286 
microprocessor and is software- and 
hardware-compatible with IBM personal 
computers. It features an 84-key key¬ 
board, a dual-mode monitor, a real-time 
clock, and interfaces for a parallel print¬ 
er, asynchronous communications, RGB 
color monitor, composite video monitor, 
and for connection to a standard televi¬ 
sion set. 


The Compaq Portable II also includes 
room for one or two mass storage 
devices. All configurations also include 
two free expansion slots and can accom¬ 
modate a maximum of 4.1M bytes of 
RAM. The main system board can be ex¬ 
panded to 640K bytes of RAM. Expan¬ 
sion up to 2.1M bytes is possible with an 
optional system memory board. 

The three models are priced between 
$3499 and $4799. Model 1 ($3499) in¬ 
cludes an 80286 microprocessor; a dou¬ 
ble density, 360K-byte disk drive; and 
256K bytes of RAM. Model 2 ($3599) 
has an additional disk drive. Model 3 
($4799) has a lOM-byte fixed disk drive. 



The Compaq Portable II. 

Address questions to Compaq Com¬ 
puter Corp., 20555 FM149, Houston, 

TX 77070; (713) 370-0670. 
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Edge! workstations incorporate supercomputer architecture 



The Edgel workstation features supercomputer architecture, according to Edge Com¬ 
puter Corp. 


Edge Computer Corp. has introduced 
the Edgel family of workstations for 
scientific, engineering, and computer- 
aided engineering, design, and manufac¬ 
turing applications. According to the 
company, the systems incorporate super¬ 
computer architecture implemented 
through 21 CMOS VLSI gate array 
chips. 

Four models make up the Edgel 
family: Model 500M, a monochromatic 
workstation; Model 500C, a color work¬ 
station; Model 500S, a network server; 
and Model 5000, a multiuser Unix sys¬ 
tem. Configurations consist of a CPU, 
real-time graphics with 1280-by-1024 
pixel resolution, a floating-point accel¬ 
erator, Edge Guaranteed Share Unix 
(AT&T System V.2 with Edge and 
Berkeley enhancements), compilers, and 
memory expansion up to 64M bytes. 

The supercomputer architecture em¬ 
ployed includes a number of features. 
The 32-bit CPU uses separate buses and 
memory groups to fetch instructions and 
access data, and pipelines instructions. A 
dual memory management unit on the 
80M-byte-per-second system bus has two 
address caches. The memory system 
consists of two eight-way interleaved 
groups that reportedly access 64 bits 
every 160 ns. The floating-point accel¬ 
erator is fully IEEE 754 compliant. Fi¬ 
nally, up to four Multibus and VME 
buses deliver an aggregate I/O band¬ 


Server/RT extends IBM PCs 

The Server/RT from Ridge Comput¬ 
ers according to the company employs 
reduced instruction set computing 
(RISC) technology to enable the IBM 
PC, PC-XT, PC-AT, and compatibles to 
perform such applications as computer- 
aided design (CAD). The Server/RT 
runs the Unix operating system and uses 
software that allows it to be connected to 
personal computers running MS-DOS or 
PC-DOS. 

The product functions as a file server, 
compute server, peripheral server, 
communications server, and database 
server. It also permits sharing of periph¬ 
erals and provides electronic mail, print 
spooling, control of source documents, 
and file security. 

The Server/RT uses the Ridge CPU, a 
300M-byte hard disk, 4M bytes of RAM, 
four RS-232 ports, two parallel ports, a 
backup drive, and a built-in Ethernet 
board and cable. It also includes the 
Unix-based Ridge operating system and 


width of 16M-bytes per second, accord¬ 
ing to the company. 

Edge intends to distribute its products 
through original equipment manufactur¬ 
ers (OEMs). Workstation prices begin at 
$45,000 in OEM quantities of 100. 


communications software. Memory is 
expandable. 

Ridge markets the Server/RT through 
value-added resellers (VARs), value- 
added dealers (VADs), and original- 
equipment manufacturers (OEMs). The 
company also signed an agreement with 
ICT-Computer Drafting Systems, in 
which ICT will market the product to 
AutoCAD end users and dealers. 


60M-byte hard disk for IBM 

CMS has announced the Econo 60, a 
60M-byte internal hard disk subsystem 
for the IBM PC and PC-XT, manufac¬ 
tured by Seagate to CMS specifications. 
The subsystem includes a CMS proprie¬ 
tary controller and cables. 

According to the company, the Econo 
60 achieves an average access speed of 37 
ms and a transfer rate of 5M bytes per 


Contact Edge Computer Inc., 7273 E. 
Butherus, Scottsdale, AZ 85260; (602) 
951-2020. 
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The Ridge Server/RT costs $35,900. 

Users of existing Ridge computers can 
purchase software to incorporate Server/ 
RT capabilities on their systems, for a 
cost of $1000. 

Contact Ridge Computers, 2451 
Mission College Blvd., Santa Clara, CA 
95054; (408) 986-8500. 
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second. It is formatted at the factory, 
but can be formatted using DOS 
commands. 

The single-unit price is $1795, with 
volume and dealer discounts available. 
Contact CMS, 401-B W. Dyer Rd„ 

Santa Ana, CA 92707; (714) 549-91 111. 
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Hard disk on a card 


OpenNet links hosts 

Intel Corp.has introduced Open 
Development Networking products that 
link host computer systems into local- 
area networks, including the OpenNet 
Network Resource Manager (NRM), 
VAX Link R2.1, OpenNet PC Link, and 
the Compilengine. 

Combined with OpenNet, Open 
Development Networking products link 
Digital Equipment Corp. (DEC) VAX 
computers, IBM PCs, and Intel’s own 
development systems and System 310 
supermicrocomputers running the iRMX 
86 or Xenix 286 operating systems into a 
network. 

OpenNet products reportedly deliver 
Ethernet/IEEE 802.3 media, ISO stan¬ 
dard message delivery protocols (8073 
class 4 transport), and MS-Net protocols 
developed by Microsoft, IBM, and InteL 

The OpenNet NRM file server pro¬ 
vides a protected hierarchical file system. 
It handles shared resources such as tape 
archive and spooled printing for all 
workstations on the network. 

VAX Link R2.1 supports file copy 
and distributed job control between 
VAX/VMS R4.2 systems and the Open- 
Net NRM. VAX Link shares the VAX 


Real-time image processing 

Imaging Technology Inc. has an¬ 
nounced the Series 150 of four board- 
level modules for computers using 
VMEbus architecture. The boards in¬ 
clude an analog/digital interface 
(ADI-150), frame buffer (FB-150), 
pipelined image processor (ALU-150), 
and real-time convolver (RTC-150). The 
primary focus, according to the com¬ 
pany, is the machine vision industry. 

The ADI-150 accepts analog input 
from up to four sensors, ranging from 
standard RS-170 or CCIR cameras to 
videocassette recorders. It digitizes the 
input signal and passes it to other 
modules for processing and storage. It 
also reconverts the stored image to 
analog form for display on a video 
monitor. The module also includes 16 in¬ 
put look-up tables (LUTs) and three out¬ 
put channels, one each for red, green, 
and blue signals. 

The FB-150 provides three separate, 
independently controllable, areas of 
memory for storing images. Pan, scroll, 
and zoom are also supported. 

The ALU-150 has 16-bit, pipelined ar¬ 
chitecture and can execute complex con¬ 
volution algorithms. It also incorporates 
conditional processing, setting status 


system’s Ethernet board and is compati¬ 
ble with DECNet. 

OpenNet PC Link uses a personal 
computer add-in Ethernet controller and 
OpenNet software to allow IBM PC- 
XTs, PC-ATs, and some compatibles to 
access files on an OpenNet server. Server 
directories appear on the PC as addi¬ 
tional DOS drives. 

The Compilengine server imports 
time-consuming compilations and link/ 
locates from systems on the network 
through distributed job control, accord¬ 
ing to the company. Features include an 
8-MHz 80286 CPU, lM-byte zero-wait- 
state RAM, and a 40M-byte Winchester 
hard disk with a controller featuring its 
own 80186 processor and 32K bytes of 
track caching. 

Intel’s OpenNet NRM with 40M-byte 
hard disk costs $14,995; it sells for 
$23,995 when equipped with 140M-byte 
hard disk and 60M-byte streaming tape 
drive. OpenNet PC Link costs $1250. 

The Compilengine sells for $13,995. The 
VAX Link sells for $7500. For more in¬ 
formation, contact Intel Corp., Litera¬ 
ture Dept. W274, 3065 Bowers Ave., 
Santa Clara, CA 95051; (408) 987-8080. 
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flags at various points in the pipeline to 
control the byte-swap circuitry and out¬ 
put LUTs. 

The RTC-150, according to the com¬ 
pany, operates at a rate of 340 MOPS 
and can perform 4-by-4 convolutions 
and 16-by-l finite impulse response 
filters at video rates. 


Planning in 3 + dimensions 

McDonnell Douglas Communications 
Industry Systems Company announced 
software using AI concepts for solving 
financial planning, analysis, and con¬ 
solidation problems. Developed for use 
on IBM MS-DOS-compatible systems, 
microCUBE is an integrated system 
designed specifically for microcomputer- 
based organizational modeling and 
business planning. 

According to the company, the prod¬ 
uct’s spreadsheet, analysis, and audit 
features organize data in unique ways. 
The company points out that Spread- 
space, unlike traditional spreadsheet pro¬ 
grams, organizes data not only in rows 
and columns but in pages also. And 
Goal Solution helps analyze results by 


Mountain Computer, Inc., has 
introduced a 30M-byte card-level hard 
disk for the IBM PC, PC-AT, PC-XT, 
and compatibles, including most 
Compaq models, the AT&T PC 6300, 
and the 6300 Plus. The DriveCard 30 
integrates two 3.5-inch disks with 
controller electronics. It runs under IBM 
DOS and Xenix operating systems. LAN 
compatibility includes Novell and 
3COM, among others. 

According to the company, DriveCard 
30 uses improved CMOS VLSI-type gate 
array technology and differs from its 
predecessors in using the advanced RLL 
2,7 encoding scheme, as opposed toMFM. 

The hard disk software is stored on 
two EPROMS, removable for updates. 
The DriveCard 30 and its integrated 
controller require one card-cage slot on 
the IBM PC-XT and one and a half slots 
on other models. The product works 
with other hard disks of any size, 
whether internal or external. 

DriveCard 30 has a suggested retail 
price of $1449. For more information, 
contact Sales Administration, Mountain 
Computer, Inc., 360 El Pueblo Rd., 

Scotts Valley, CA 95066; (408) 438-6650. 
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Prices are $2995 for the ADI-150, 
$2995 for the FB-150, $1995 for the 
ALU-150, and $3995 for the RTC-150. 
For more information, contact Imaging 
Technology Inc., 600 W. Cummings 
Park, Woburn, MA 01801; (617) 
938-8444. 
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determining the inputs necessary to reach 
them. Using color coding, Visual Audit 
can identify values that have been input, 
locked, recalculated, or not changed. 
microCUBE can be configured with 
communications and graphics features at 
additional cost. 

Initially being presented to the com¬ 
pany’s telecommunications industry 
clients, the product will soon be available 
to a national and international market at 
a price of $1200. 

For more information, contact 
McDonnell Douglas, 7535 E. Hampden 
Ave., Suite 200, Denver, CO 80231; 

(303) 695-1500. 
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BlueFish provides publishing tool 


Computer Access Corp. has an¬ 
nounced BlueFish, a publishing tool for 
text management with IBM PCs and 
compatibles. The software handles 
ASCII files, allowing users to add or 
delete documents, search (by word, 
phrase, or wildcard), and sort alphabeti¬ 
cally or numerically. According to the 
company, users can also create text data¬ 
bases from source code for programming 
help. 

BlueFish operates on a PC with a 
minimum configuration of 256K bytes of 
memory, a floppy disk and PC-DOS. It 
is packaged in two configurations: as an 
office automation full text management 
system and as a search and retrieval 
module. The former includes build and 
search/retrieval modules and targets PCs 
equipped with a hard disk, for informa¬ 
tion workers or other professionals. The 
latter targets publishers of data distrib¬ 
uted on optical or other mass-storage 
media. 

BlueFish employs English-language 
syntax for commands and operations, 
conducts Boolean and range searches, 
and is written in C and Assembler. Al¬ 


though independent of media, according 
to the company it works best with one or 
more hard disks, optical write-once-read- 
many (WORM) disks, or CD-ROM 
disks. 

Computer Access Corp. markets 
BlueFish principally through licensed 
original-equipment manufacturers 
(OEMs). Prices start at $750 for a single- 
user, single-site license. A single-user, 
entry-level publishing license, which en¬ 
titles a user to one program and the right 
to put one copy of the search and re¬ 
trieval software on each of fifty disks but 
without rights to redistribution, costs 
$3500. An evaluation package that con¬ 
sists of the documentation and two flop¬ 
py disks containing the search and re¬ 
trieval command set costs $100, that 
amount being applied toward the license 
price if the complete package is pur¬ 
chased within 30 days. 

For more information, contact Com¬ 
puter Access Corp., 26 Brighton St., 

Suite 324, Belmont, MA 02178-4008; 

(617) 484-2412. 
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Sharp's PROMIS for computer-integrated manufacturing 


1. P. Sharp has announced semicon¬ 
ductor manufacturing software that runs 
on Digital Equipment Corporation 
MicroVAX II hardware. PROMIS, for 
PROcess Management and Information 
System, is a directive, real-time shop 
floor control system with planning, 
tracking, reporting, and engineering 
analysis capabilities. 

As a directive system, the product 
instructs workers in what to do at each 
workstation. At the same time, it checks 
input data for validity. 

As related by the company, individual 
automation modules are available for a 
variety of makes and models of process 


System 19 built on ASP 

Counterpoint Computers has an¬ 
nounced the System 19 family of com¬ 
puters built on the company’s advanced 
system platform (ASP). According to the 
company, the architecture features a 
hybrid system design called distributed 
dual-port memory in which each pro¬ 
cessor has local tightly coupled memory 
but can gain direct access over the system 
buses to the memory of up to seven com¬ 
panion processors. 

Three basic system configurations with 
single or multiple processors are graphics 
(monochrome or color), multiuser 


equipment. Process engineers can use the 
product to describe facilities and “rec¬ 
ipes,” while managers and sales support 
personnel use the system to enter 
demand data and create schedules. 

On the factory floor PROMIS’s 
reporting capability tracks activity and 
provides productivity, yield, cycle time, 
and inventory data, the company claims. 

A minimum MicroVAX configuration 
capable of controlling a fab facility 
would include the computer, with 5M 
bytes of main memory, plus two DEC 
RA-81 disk drives. In its fullest configu¬ 
ration, a MicroVAX II with 9M bytes of 
main memory and four RA-81 disk 


(ASCII, bit-mapped, or mixed), and 
servers (database, file, or compute). The 
systems are based on the Unix System V 
operating system and the Motorola 
68020 microprocessor. They can be con¬ 
figured with from one to eight VLSI mi¬ 
croprocessors, from 1 to 40M bytes of 
RAM, and from 50 to 560M bytes of 
Winchester disk storage. 

Counterpoint provides networking ex¬ 
tensions from the Berkeley 4.2 Unix im¬ 
plementation, the C-XIX (C-19) operat¬ 
ing system, to support local-area net¬ 
works. The system offers an icon-based, 


LabSoft for IBM DACA 

Wiley Professional Software has 
announced LabSoft, originally devel¬ 
oped by Cyborg Corp. for use with its 
Isaac series of computer-based data 
acquisition and control systems. LabSoft 
works with the IBM PC, PC-XT, and 
PC-AT in conjunction with the IBM 
Data Acquisition and Control Adapter 
(DACA). 

According to the company, LabSoft 
offers complete language compatability. 
It comes in three versions: Fortran, 

Basic, and C. 

LabSoft’s more than 40 programming 
tools and commands include asynchro¬ 
nous (background/foreground) execu¬ 
tion, analog I/O, binary I/O, Schmitt 
trigger functions, counter functions, 
thermocouple functions, and FFT. 
LabSoft also includes graphic subrou¬ 
tines and an interface to Lotus 1-2-3. 

The Fortran and Basic versions cost 
$350 each and the C language supple¬ 
ment, $75. Contact Wiley Professional 
Software, 605 Third Ave., New York, 

NY 10158; (212) 850-6788. 
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drives could support as many as 32 
directly connected pieces of production 
equipment or terminals. 

PROMIS computer-integrated manu¬ 
facturing software is modular and, 
according to the company, can be 
tailored to each customer’s application. 
An entry-level system for the MicroVAX 
II is immediately available and costs 
$138,000. 

For more information contact I. P. 
Sharp Associates, 4699 Old Ironsides 
Dr., Suite 300, Santa Clara, CA 95054; 
(408) 748-9822. 
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object-oriented shell for novices, but also 
provides complete access to the C-shell 
and Bourne shell of the Unix operating 
system. 

System 19 supports four languages: a 
C compiler, Fortran-77, Pascal, and 
Common Lisp. 

The multiprocessor systems begin at 
$17,200. Single-processor systems start at 
$13,000. Contact Counterpoint Com¬ 
puters, 2127 Ringwood Ave., San Jose, 
CA 95131; (408) 434-0190. 
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Tektronix offers software development tools 



The Multi-V Systems from Tektronix are hosted on VAX computers. They provide a 
software development environment and a software/hardware integration environment 
for Motorola’s 68020 and Intel’s 80286 microprocessors. 


Tektronix, Inc., has announced the 
Multi-V Systems, a 32-bit software devel¬ 
opment environment and software/ 
hardware integration environment for 
Motorola’s 68020 and Intel’s 80286 mi¬ 
croprocessors, and Structured Design 
(SD) Tools, a set of graphically-oriented 
software development tools. 

Multi-V Systems include language sup¬ 
port for the 68020 and 80286, including 
C Language Development Systems 
(Clands II) and software executors. 
Software/hardware integration support 
includes a 68020 emulator and an 80286 
emulator. The systems are hosted on 
VAX family computers from the Micro- 
VAX II to the VAX 8800 running VMS, 
Ultrix, or Unix 4.2 BSD. 

Entry-level systems start under 
$20,000. Costs vary according to the 
configuration. For more information, 
write SDP Division Marketing, Attn: 
32-Bit Support, Tektronix, Inc., PO Box 
14752, Portland, OR 97214; (513) 
629-1573. 

Structured Design Tools automate the 
graphic functions of drawing and modi¬ 
fying diagrams, according to the com¬ 
pany, and range in price from $4500 to 


$9500 depending on the host computer. 
SD Tools operate on the VAX, Micro- 
VAX II, or Tektronix’ 856X series devel¬ 
opment systems. For more information, 


write to the same address but Attn: SD 
Tools. 
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Trilobyte V/PC weathers MacroEdge helps design ICs 
severe environments 


Trilobyte Computer Corp. has an¬ 
nounced the V/PC, an industrial PC for 
the NEMA 4 environment. The V/PC 
isolates the guts of a Zenith Z-158 PC on 
helicoil shock mounts in a sealed enclo¬ 
sure with a passive heat exchanger. 

According to the company, the V/PC 
is designed for severe industrial and field 
mobile environments with humidity/ 
hose-off, corrosive gases, conductive 
particulates, or other unfilterable 
contaminants. 

The V/PC uses the Zenith passive 
backplane PC-XT implementation with 
all logic on standard plug-in modules. 
The basic system occupies two Zenith 
slots, leaving one Zenith slot and five 
standard PC slots free. Mounting is pro¬ 
vided for one full-high plus one half-high 
drive. The whole is housed in an alumi¬ 
num Mil-Spec case partitioned into ex¬ 
terior and sealed interior air paths. 

The Trilobyte V OEM Chassis costs 
$4995 in quantities of ten. Base systems 
with the Zenith Z-158 single floppy sys¬ 
tem cost $9950 in single quantities. 

For more information, contact Trilo¬ 
byte Computer Corp., 801 W. Grand 
Ave., Oakland, CA 94607; (415) 
839-1100. 
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SDA Systems has announced Macro- 
Edge, a design system for placement and 
automatic routing of integrated circuits 
consisting of variable shape blocks. Ac¬ 
cording to the company, MacroEdge au¬ 
tomatically interconnects cells and offers 
unlimited levels of design hierarchy. 

Included are tools for library manage¬ 
ment, floor planning, automatic assisted 
macro cell placement, routing channel 
generation, global routing, channel rout¬ 
ing, and layout verification. The system 
handles CMOS, NMOS, Bipolar, and 
Gallium Arsenide designs. 


Entry from other design systems oc¬ 
curs through the electronic design inter¬ 
change format (EDIF). A Calma GDSII 
Stream data translator handles output to 
mask-making machines and in-house 
verification systems. 

Prices begin at $60,000; $113,000 for 
turnkey systems. Contact SDA Systems, 
2461 Mission College Blvd., Santa Clara, 
CA 95054; (408) 727-7811. 
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Elxsi adds Quad and Dyad to System 6400 family 

Elxsi has added two members to the CPU, memory, and I/O capability can 

System 6400 family of computers. Ac- be added by field upgrades, 

cording to the company, the four-CPU Typical applications include computer- 

Quad achieves 28 Whetstone MIPS and aided design and engineering, aero- 
the two-CPU Dyad achieves 14 Whet- nautical research, data processing in 
stone MIPS. Each system comes with telephone operating companies, and de- 
32M bytes of main memory. velopment of front-end processing for 

Quad and Dyad also feature a 320M- supercomputers, 
byte-per-second system bus coupling up Quad costs $695,000 and Dyad 
to 12 symmetric CPUs, physical memory $520,000. For more information, contact 

expansion up to 192M bytes, availability Elxsi, 2334 Lundy Place, San Jose, CA 
of AT&T System V Unix and BSD 4.2 95131-1873; (408) 942-0900. 

Unix operating systems, and Elxsi’s 

proprietary EMBOS operating system. Reader Service Number 61 
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miniForce based on VMEbus 


Model 850 joins RPMs 

Versatec, a Xerox company, has an¬ 
nounced the Model 850 Raster Process¬ 
ing Machine (RPM) for plotting systems 
not locally or channel attached to main¬ 
frame computers. The product joins the 
Model 800 RPM series of rasterizing 
controllers. It offloads the data ordering 
and rasterization process and processes 
all Versatec data standard types (ran¬ 
dom, ordered vector, compressed raster, 
and blocked raster). 

Three versions of the Model 850 RPM 
are available, including the Dual Density 
800/1600 45 ips low speed ($30,000), 
Dual Density 800/1600 ips high speed 
($36,000), and Tri-density 800/1600/6250 
45 and 75 ips ($50,000). 

Rugged disk is removable 

Rolm Mil-Spec Computers, a 
subsidiary of Loral Corp., has intro¬ 
duced the Model 4100 Small Disk. This 
rugged disk subsystem features 3.5-inch 
Winchester technology, 20M bytes of 
storage, and a removable hard disk 
assembly (HDA). 

Removal of the HDA permits transfer 
of data among systems and physical 
removal for protection of sensitive data. 



Versatec Model 850 RPM has off-line 
plotting. 


For more information, write Versatec, 
a Xerox Company, 2710 Walsh Ave., 
Santa Clara, CA 95051; (408) 988-2800. 
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An internal small computer standard 
interface (SCSI) allows the Small Disk to 
communicate with any Rolm Mil-Spec 
computer or SCSI-compatible host 
processor, such as the IBM PC. 

Model 4100 costs $11,500. For more 
information, contact Rolm Mil-Spec 
Computers, One River Oaks Place, San 
Jose, CA 95134; (408) 942-8000. 
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Force Computers, Inc., has introduced 
a series of VMEbus-based computer sys¬ 
tems combining the 68000 family micro¬ 
processors with the PDOS operating sys¬ 
tem. 

The high-end, four-user miniForce- 
2P5 uses a 68000 microprocessor 
operating at 16 MHz coupled with 128K 
bytes of local RAM operating with no¬ 
wait states, 2M bytes of global VME 
RAM, a 50M- byte hard disk, and a 
lM-byte floppy disk. 

The low-end, two-user miniForce-lPl 
features 512K bytes of DRAM, a 20M- 
byte hard disk, and a lM-byte floppy 
disk. 

Main features of the miniForce series 
include a 68000 processor at 8, 10, 12.5, 
or 16 MHz or a 68010 microprocessor at 
8, 10, or 12.5 MHz; two to eight RS-232 
serial ports; 412K bytes to 2M bytes of 
main memory; 25M-byte or 50M-byte 
Winchester drive; lM-byte floppy disk; 
PDOS real-time operating system; two to 
six extra VMEbus slots; and optional 
languages. 

Prices range from $8385 for the 
miniForce-lPl to $14,895 for the 
miniForce-2P5. Contact Force Com¬ 
puters, Inc., 727 University Ave., Los 
Gatos, CA 95030; (408) 354-3410. 
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Pride, Progress 
& Productivity 

Three over-riding management strategies have enabled Presearch 
Incorporated to maintain a special niche in the fast changing 
world of high tech professional services: 

• Unfailing dedication to improving state-of-the-art in systems, 
methods and equipment. 

• Maintaining the responsive, “can-do” character of a small com¬ 
pany, even though we have grown steadily in our 22 years. 

• Attracting and maintaining the most qualified staff, commit¬ 
ted to the highest professional standards. 

Presearch is a valued source of professional answers to difficult 
questions posed by DOD, DOE and commercial clients. Our 
reputation for excellence extends from Information Systems Plan¬ 
ning, Design, and Implementation in mainframe and micro envi¬ 
ronments to Software Engineering/Design and Operational 
Analysis. We are developing office systems in ‘C,’ realtime com¬ 
mand and control systems in Ada, and are deeply committed to 
in-house funded R&D in Ada software engineering, embedded 
systems design, and software tools development. 

Recent expansion has created the need for bright, energetic 
Computer Scientists and Engineers who are seeking to share the 
spirit, enthusiasm and “can-do” environment at Presearch. 

For immediate consideration, call J. Wamstad at 
(703) 876-6404 or send your resume in confidence to: 
Presearch, 8500 Executive Park Avenue, Department IE, 
Fairfax, Virginia 22031. An Equal Opportunity Employer. 

U.S. citizenship required. 

Ptesearch 


Let Us Place You 

— IN A 

BETTER JOB NOW 


Put our 20 years of experience placing technical professionals to 
work for you. Client companies pay all fees, interview and relo¬ 
cation costs. You get our expert advice and counsel FREE. 
Nationwide opportunities in Communications, Defense, Intelli¬ 
gence, Computer, Satellites, and Aerospace Systems. 

We are seeking individuals with experience and interest in one 
or more of the following areas: 

• Software Configuration Management 

• Data Base Design and Development 

• Distributed System Design and Development 

• VAX Software Development Under VMS 

• IBM 4341 Software Development 

• FORTRAN and MACRO Programming 

• Military Standard Systems Design and Development 

• Local Area Networks 

• Color Graphics Display Software Design 

• Rapid Prototyping 

• Software Quality Assurance 

• Artificial Intelligence 

• Test Planning and Testing 

• Verification and Validation 


Salaries range from 
$30,000-575,000 plus. 
U.S. citizenship 
required. EBI/SBI 
desirable. Let us place 
you in a better, more 
rewarding job . . . now. 
Send your resume in 
confidence to: 

Dept. CA-IC 


WALLACH 

associates, inc. 


Washington Science Center 
6101 Executive Boulevard, Box 6016 
Rockville, Maryland 20850-0616 



Wallach . . . Your Career Connection 
























How do great minds get great ideas? 



...with a little help from their friends. 

Designing a state-of-the-art personal computer is no mean trick. Ask Jay Miner, chief architect of the Commodore Amiga. 
Miner had to rely on more than his best friend and colleague, Mitchie, for the creative insights that led to his new product 
(though Mitchie did lend her pawprint to adorn the inside of the Amiga case). 

He also had to know what his other friends and colleagues in the microprocessor world were doing. He found out by 
reading IEEE MICRO—the IEEE Computer Society magazine on microprocessor architectures and systems. 

Along the way, Miner made a friend, or shall we say, an Amiga. 

Keep in touch with your friends and get some great ideas. Read IEEE MICRO. 


□ Sister Society rate: $25/year (six issues) 

If you are a member of an affiliate society such as ACM, 
ASME. DPMA, SAE. SIAM, or any other professional 
technical society, you are eligible for this special rate. 


Signature 




Address 


Zii 


□ Computer Society or any other IEEE Society 
member rate: $15/year (six issues) 

Membership Number_ 


Charge Card Number 


Return to: IEEE Computer Society, 10662 Los Vaqueros Circle, 
bos Alamitos, CA 90720-2578 
or Call: JEEE Computer Society offices at 

Calif. (714) 821-8380 / Belgium 011(02) 660-1143 


□ Bill me 

□ Check enclosed 
CJ Visa 

□ MasterCard 

□ American 
Express 
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City 


State 
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Recent Microsystem Announcements 


For more information, circle the appropriate RS No. on the Reader Service Card at the back of the magazine. 


MANUFACTURER R.S. 

AND MODEL FUNCTION COMMENTS No. 


Alsys, Inc., Compiler 

Alsys PC AT Ada 

Compiler 


This product, which is packaged with a 4M-byte memory board, permits an 
application program to access extended memory (up to 16M bytes). It generates 
8086 instructions for the IBM PC XT or IBM PC AT; or 80286 instructions for the 
IBM PC AT only (executable object code). Cost: $3000 (in the US). Alsys, Inc., 
1432 Main St., Waltham, MA 02154; (617) 890-0030. 


Data Translation, Data Designed for the IBM PC AT, this board features 16-bit resolution, a throughput 81 

Inc., acquisition of 100 kHz, four channels of differential analog input, two 12-bit DACs, 16 lines 

DT2827 board of digital I/O, a channel RAM list, a programmable clock, and support for inter¬ 

rupts and DMA transfers. Cost: $2495. Data Translation, Inc., 100 Locke Dr., 

Marlboro, MA 01752; (617) 481-3700. 


The Destek Group, LAN This unit includes an enhanced version of Destek’s 2M bps board-level 82 

LAN for Concurrent hardware and software compatible with Concurrent CP/M-86. In addition to 

CP/M-86 Concurrent CP/M, users can combine network systems that incorporate 

CP/M-86 or MPM II operating systems. Three versions are available: for S-100, 

IBM PC, and Multibus hardware. Prices begin at $600. The Destek Group, 830 E. 

Evelyn Ave., Sunnyvale, CA 94086; (408) 737-7211. 


Earth Computers, Single-board 

Turboslave-PC processor 


The Turboslave-PC is a Z-80-based, 8-MHz, single-board processor designed for 83 
the IBM-PC family and compatibles. It is supported by the Turbo-DOS operating 
system, which will support up to 16 Turboslave-PC processor boards connected 
to a PC, and it can be configured as a coprocessor under the MS-DOS operating 
system. Cost: $395. Earth Computers, Box 8067, Fountain Valley, CA 92728; 

(714) 964-5784. 


Everex Systems, Streaming- 

Inc., tape system 

Excel-Stream 60-8 


A system with a 60M-byte storage capacity, the Excel-Stream 60-8 is designed 84 
for the IBM PC family and compatibles. A free-standing, 8-inch form factor unit, 
it provides backup as fast as 10M bytes in two minutes on industry-standard 
streaming tape cartridges. Cost: $995. Everex Systems, Inc., 47777 Warm 
Springs Blvd., Fremont, CA 94539; (415) 498-1111. 


Force Computers, Software 

Inc., design tool 

MicroFORCE-IA 


This Unix-on-VMEbus product implements AT&T’s Unix V (Release 1.0) on a 85 

68010 microprocessor, with 128K-byte local no-wait-state memory, 2M bytes of 
global VME main memory, one VME expansion slot, and 50M bytes (unfor¬ 
matted) of Winchester storage. Cost: $8995. Force Computers, Inc., 727 Univer¬ 
sity Ave., Los Gatos, CA 95030. 


Fort’s Software, 
V-EMM 


Harris Corp., 
Concept 4300 


Virtual 

expanded 

memory 

manager 


V-EMM is a software package designed to provide true virtual memory capabil- 86 
ity for various programs that support the Lotus/Intel/Microsoft Expanded 
Memory Specification. Minimum requirements: an IBM personal computer or 
compatible, IBM PC-DOS (Versions 2.0, 2.1, 3.0, or 3.1), 128K of conventional 
memory, an EMS-compatible board, 256K of expanded memory, and an IBM 
Fixed Disk Drive and Fixed Disk Adapter (or compatible). Cost: $89.95. Fort’s 
Software, PO Box 396, Manhattan, KS 66502; (913) 537-2897. 


PC workgroup The Concept 4300 incorporates Perspective, a transparent common interface 87 
server environment that allows the user to select an application function without 

having to know whether the application must run in Xenix, MS-DOS, or H-DOS 
(Harris’s proprietary operating system). It can accommodate up to eight PC 
workstations. These may include any IBM-compatible PC and the Concept 2100 
medialess PC workstation. Price not indicated. Lanier Business Products, Inc., 

1700 Chantilly Dr., NE, Atlanta, GA 30324; (404) 329-8000. 


Hayes Communi- 

Microcomputer cations 

Products, Inc., software 

Smartcom II for the 
PC Network 


This package is designed to enable IBM PCs on an IBM PC Network to share 88 
modems and asynchronous communications ports and to make use of all the 
functions Smartcom II currently provides for single-user PCs. Cost: $599. Hayes 
Microcomputer Products, Inc., PO Box 105203; Atlanta, GA 30348; (404) 

449-8791. 
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MANUFACTURER 
AND MODEL 


FUNCTION 


COMMENTS 


R.S. 

No. 


Honeywell 

Optoelectronics 

Division, 

HFM-5210 


Independent 
Business Systems, 
Inc., 

3000 Series 
Ultraframe, 

4000 Series 
Ultraframe 


Interloop, 
Model 210 


John Fluke Mfg. Co., 
Inc., 

Helios I Computer 
Front End 


MAI Basic Four, 
Inc., 

MAI 1500 


McGraw-Hill 

Software, 

Maxit 


Multi-Tech Systems, 
Inc., 

MultiModemPC3 


Rolm Mil-Spec 
Computers, 
Model 3557 LINC 


SBE, Inc., 
SBE/M LAN-11 


Visionics Corp., 
EE Designer 


Votan, 

PC Executive 
Secretary 


Modem 


Micro¬ 

computers 


I/O interface 


Data 

acquisition 
and control 
subsystem 


Business 

Basic 

computer 

system 

Memory card 
and software 


Modem 


Intelligent 

Ethernet 

controller 


LAN front-end 
processor 


CAE/CAD 

software 

package 


Voice 

recognition 

system 


The HFM-5210 has full duplex asynchronous operation up to 19.2K bps. It plugs 89 
directly into standard RS-232, 25-pin ports, and the fiber-optic interface can be 
either AMP-SFR or Amphanol-SMA. Cost: $96.10 (single units); $74.68 (500’s). 
Honeywell Optoelectronics Division, 830 E. Arapaho Rd., Richardson, TX 75081; 
(800)-FOR-OPTO. 

IBS has announced 16-bit models of the 3000 Series, which comes in versions 90 
with storage capacities ranging from 11M bytes to 170M bytes, and its 4000 
Series, which comes in versions with storage capacities ranging from 300M 
bytes to 1160M bytes. They are based on IBS’s 80186 slave processor boards, 
incorporate an IEEE-696 standard S-100 bus architecture, and can support up to 
32 users in the same chassis. Cost depends on version purchased. Indepen¬ 
dent Business Systems, Inc., 5915 Graham Ct., Livermore, CA 94550; (415) 

443-3131. 

Features: TTL-compatible I/O from HPIL; four 8-bit output ports; two 8-bit input 91 
ports; eight analog input channels; on-board analog reference, offset, and 
- 12V converter; HPIL-readable DIP switch; Centronics-compatible output; byte 
and bit output operation; seven time increment counters; and seven event 
counters. Price not indicated. Interloop, 2000-7 Wyatt Dr., Santa Clara, CA 
95054; (408) 986-9707. 

Intended as a smart intermediary between a computer and a real-world 92 

measurement application, Helios I is designed to communicate to any host 
computer over standard RS-232 or RS-422 interfaces. It can be extended to 1500 
channels. Configuration and programming instructions are included for the IBM 
PC, Tandy TRS-80, Apple lie, DEC PDP-11, and Micro VAX. Cost: $1995. John 
Fluke Mfg. Co., Inc., PO Box C9090, Everett, WA 98206; (800) 426-0361. 

This low-end IBM PC AT-compatible system is designed for one to three users. 93 
It consists of a main monitor and optional display terminals, and includes the 
MAI Business Basic Language and Concurrent/DOS (C/DOS). Cost not 
indicated. MAI Basic Four, Inc., 14101 Myford Rd., Tustin, CA 92680; (714)731-5100. 

Maxit expands available memory on the IBM PC family and compatibles. It 94 

increases by up to 256K bytes the available work space for a spreadsheet 
created with Lotus 1-2-3 (Release 1A). Cost: $195. McGraw-Hill Software, Suite 
1350, 8111 LBJ Fwy„ Dallas, TX 75251; (214) 437-7422. 

A half-card 1200/300 bps modem that will operate in all half- or full-length board 95 
slots in the IBM PC family and compatibles, MultiModemPC3 features Hayes 
AT command set compatibility, and autodial and auto-answer capability. It is 
asynchronous, includes two phone jacks and built-in speaker, and offers half or 
full duplex operation. Cost: $299. Multi-Tech Systems, Inc., 82 Second Ave., SE, 

New Brighton, MN 55112; (612) 631-3550. 

Designed for military computers, this single-card device manages the 96 

movement of data onto and off of IEEE 802.3/Ethernet-compliant networks 
based on Rolm Mil-Spec processors and computers produced by various other 
vendors. Both Ethernet and IEEE 802.3 hardware protocols can be used to 
provide half-duplex, synchronous serial transmission at 10M bps. Price not 
indicated. Rolm Mil-Spec Computers, One River Oaks PI., San Jose, CA 95134; 

(408) 942-8000. 

This plug-in board can be used as an Ethernet node processor functioning as a 97 
slave Ethernet Multibus controller, or it can be a packaged “black box” with a 
power supply to function as a stand-alone serial/parallel/SCSI gate to the 
Ethernet highway. Cost: $1495 (100’s). SBE, Inc., 2400 Bisso Lane, Concord, CA 
94520; (800) 221-6458. 

EE Designer runs on the IBM PC, XT, or AT or compatibles with 512K of mem- 98 
ory. It consists of three integrated programs designed for schematic design, 
circuit simulation, and PCB layout. Input is through a mouse or digitizer, and 
display graphics use a standard IBM color board or a 640 x 400 pixel high- 
resolution Tecmar graphics board. Cost: $975. Visionics Corp., 1284 Geneva Dr., 
Sunnyvale, CA 94089; (408) 745-1551. 

Designed to add voice communications, continuous voice recognition, and 99 

telephone management capabilities to IBM PCs and compatibles, PC Executive 
Secretary includes voice board, telephone management software, telephone 
interface, speaker, and microphone. Cost: $1695. Votan, 4487 Technology Dr., 

Fremont, CA 94538; (415) 490-7600. 
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Recent 1C Announcements 


For more information, circle the appropriate RS No. on the Reader Sen/ice Card at the back of the magazine. 


MANUFACTURER r s 

AND MODEL_FUNCTION COMMENTS No! 


General Instrument, Optocoupler 
Optologic 


National Micro- 

Semiconductor controllers 

Corp., 

HPC family 


NCR Corp., Controller 

53C80 


NEC Electronics Digital signal 

Inc., processor 

UPD77230 


Oki Semiconductor, Digital signal 
M77C20 processor 


Raytheon Co., CMOS logic 

RL7000 family gate array 


Sierra Cell library 

Semiconductor 

Corp., 

Triple Technology 


Toshiba America, Static RAM 
Inc., 

TMM2078D-35 


This optically-coupled logic interface gate features typical propagation delay of 70 
60 ns, isolation voltage of 2500 VRMS, working voltage of 440 VRMS, minimum 
common mode (CM) transient immunity of 5000 V/^s, with a typical CM of 15000 
V/ms. Four interface types include LSTTL to TTL (740L6000, 740L6001) and 
LSTTL to CMOS (740L6010, 740L6011), as a buffer or inverter. Cost: $2.55 
(1000’s). General Instrument, Optoelectronics Div., 3400 Hillview Ave., Palo Alto, 

CA 94304; (415) 493-0400. 

The core processor, rated at 17 MHz, is a 16-bit CPU with six working registers, 71 
a microninstruction ROM, clock generator, serial I/O bus, three 16-bit timer 
counters, control logic, watchdog and reset circuitry, and a Microwire/Plus 
interface. The first member, HPC16040, is a microcomputer on one chip, with 
4K bytes of ROM, 256 bytes of RAM, 52 I/O lines eight 16-bit timers, and an on- 
chip universal asynchronous receiver-transmitter. The HPC16040R (ROMIess 
version) comes in a 68-pin plastic leadless chip carrier (PLCC) in industrial 
temperature grade (- 40 to 85 degrees C). The HPC16040 is also available in 
extended temperature range (- 55 to 125 degrees C) in a 68-pin ceramic 
leadless chip carrier. Cost: $29.90. National Semiconductor Corp., 2900 
Semiconductor Dr., PO Box 58090, Santa Clara, CA 95052-8090; (408) 721-5000. 

This CMOS version of the 5380 small computer system interface (SCSI) chip is 72 
functionally equivalent to NCR’s NMOS-based 5380. Four ground lines have 
been added. The 53C80 communicates with the microprocessor as a peripheral 
device. It supports bus arbitration and selection and reselection commands. 

Cost: $13.65 (1000’s). NCR Corp. is located in Dayton, OH 45479. NCR’s 
semiconductor distributors will handle distribution. 

This CMOS device has on-chip 32-bit floating point architecture with a 55-bit 73 
floating point multiplier. It achieves 12.4 million Mflops. The uPD77230 ad¬ 
dresses external memory for data and instruction and has two separately ad¬ 
dressable RAM blocks. It comes in a 68-pin grid array package. Cost: $260 
(100’s). NEC Electronics Inc., 401 Ellis St., PO Box 7241, Mountain View, CA 
94039; (415) 960-6000. 

Developed jointly by Oki and NEC, this single-chip DMOS DSP is functionally 74 
compatible with NEC’s uPD7720 NMOS DSP and interfaces with all of Oki’s 
microprocessor families. A 16-bit, fixed-point microcomputer, it has a four-level 
program stack and supports a single-level interrupt. Cost: $25 (100’s, with a 
minimum order of 2500), with a $5000 tooling charge. Oki Semiconductor, 650 
N. Mary Ave., Sunnyvale, CA 94086; (408) 720-1900. 

The RL7000 series has eight masterslice options and interfaces with LSI Logic 75 
Corp.’s LDS system, Mentor, VAX-Tegas, VAX-MEDS, and Calma GDSII. The 
logic arrays operate at 1.4 ns/gate. A variety of products are available to meet 
commercial or military temperature ranges and screening and qualification 
according to Mil-Std-833, classes B and S. One production line is certified to 
meet Mil-M-38510. NRE costs to customer: $25,000-$75,000. Consult Raytheon 
for unit prices. Raytheon Semiconductor Div., 350 Ellis St., Mountain View, CA 
94059-7016; (415) 966-7716. 

This standard-cell library includes electrically erasable memory cells, analog 76 

and digital cells, and a set of CAD tools. The electrically erasable memory cells 
provide on-chip, nonvolatile storage of calibration parameters, access codes, 
and other tailoring data, and on-chip replacements for potentiometers, 
switches, jumper wires, and other calibrating, adjusting, and programming sys¬ 
tem functions. Cost: depends on the custom cell design. Sierra Semiconductor 
Corp., 2075 N. Capitol Ave., San Jose, CA 95132; (408) 263-9300. 

This NMOS static RAM has 35 ns access time and an output enable function. 77 
Choosing chip-select input deselects the device and places it in a standby 
mode with maximum current of 20 mA. Maximum operating current is 150 mA. 

All inputs and three-state outputs are TTL compatible. Cost: $7.35 (1000’s). 

Toshiba America, Inc., 2692 Dow Ave., Tustin, CA 92680; (714) 832-6300. 
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NEW LITERATURE 


Unix shells, AI applications. Lowell Jay 
Authur’s Unix Shell Programming 
($22.50) guides Unix users through shell 
programming. A short review of the 
basics is followed by explanations of 
how to make applications run smoothly, 
ensure maintainability, and increase effi¬ 
ciency. Paul Harmon’s Expert Systems 
Applications ($19.95) covers artificial in¬ 
telligence as applied in management, 
sales, operations, programming, re¬ 
search, and service industries. Both 
books are from John Wiley & Sons, 

Inc., Publishers, 605 Third Ave., New 
York, NY 10158; (212) 850-6336. 

New from McGraw-Hill. Programming 
with Turbo Pascal by David W. Carrol 
(ISBN 0-07-852908-5) is a tutorial pack¬ 
age with manual and disk for IBM PCs 
and compatibles. It costs $34.95 and 
covers the basics of programming in 
standard Pascal before tackling Turbo 
Pascal. The disk includes a limited Tur¬ 
bo Pascal compiler. Contemporary Elec¬ 
tronics Circuits Deskbook, edited by 
Harry L. Helms, is a compilation of cir¬ 
cuit designs and applications taken from 
recent electronics magazines, applica¬ 
tions notes, and databooks. This refer¬ 
ence describes each circuit, including 
component values, construction hints, 
and restrictions on use. It examines such 
areas as transmitters and receivers, 
audio circuits, test and measurement, 
video and television, digital circuits, 
automotive circuits, and telephone cir¬ 
cuits. ISBN 0-07-027980-2, $29.95. 
McGraw-Hill Book Company, 1221 
Avenue of the Americas, New York, 

NY 10020; (212) 512-3493. 

Market forecasts. Input has published 
two reports on market conditions for 
U.S. turnkey systems and federal pro¬ 
fessional services. U.S. Turnkey Systems 
Markets: 1985-1990 reports on the 
market size and growth rates of the 
U.S. turnkey market by 13 industry- 
specific segments, as well as overall 
cross-country and custom turnkey mar¬ 
kets and forces influencing the market. 
Federal Government Professional Ser¬ 
vices Market warns of the difficulty of 
penetrating the federal professional ser¬ 
vices market and the consequent nar¬ 
rowing of profit margins. The report 
analyzes and forecasts the market from 
both the commercial vendor and agency 


view. The report recommends ap¬ 
proaches to successfully penetrate the 
federal professional services market. 
Both reports are available for $995 each 
from Input, 1943 Landings Dr., Moun¬ 
tain View, CA 94043; (415) 960-3990. 

Component Technology and Standard¬ 
ization Manual was developed by Gen¬ 
eral Electric to help their engineers 
select the right component characteris¬ 
tics for a design application. The three- 
volume manual costs $495 in the U.S. 
and Canada, $575 via air overseas. An 
updating service costs $140/yr. in the 
U.S. and Canada, $190/yr. via air over¬ 
seas. A 15 percent discount is available 
for orders of two or more sets. Order 
from Genium Publishing Corp., 1145 
Catalyn St., Dept. CT6A-1, Schenec¬ 
tady, NY 12303-1836, USA; (518) 
377-8854. 

The Electronic Encyclopedia from 
Grolier Electronic Publishing provides a 
compact disk, read-only memory ver¬ 
sion of the 20-volume Academic Ameri¬ 
can Encyclopedia for use with Philips, 
Sony, and Hitachi CD-ROM disk drives 
and most personal computers. It is now 
available for the IBM PC with 256K 
bytes and is scheduled for Apple He’s 
(equipped with a 68000 card) and Atari 
520 STs. Cost: $199. Contact Grolier 
Electronic Publishing, Inc., 95 Madison 
Ave., New York, NY 10016; (212) 
696-9750. 

Business Software Directory lists over 
7000 software packages and services. It 
is backed by an on-line computer data¬ 
base, the Business Software Database. 
Multiple indexes include the name of 
the vendor; name of the program; type 
of application, industry, or function; 
name of the hardware; and type of op¬ 
erating system. The 1700-page directory 
costs $175. Information Sources, 1807 
Glenview Rd., Glenview, IL 60025; 

(312) 724-9285. 

Managing office technology. Knowledge 
Industry Publications has published a 
guide for general managers, human re¬ 
source directors, and others concerned 
with the introduction of new office 
technology, based on a two-year nation¬ 
al field study led by Alan F. Westin. 

The Changing Workplace: A Guide to 


Managing the People, Organizational 
and Regulatory Aspects of Office Tech¬ 
nology (ISBN 0-86729-164-8) is available 
for $49 from Knowledge Industry 
Publications, Inc., 701 Westchester 
Ave., White Plains, NY 10604; (914) 
328-9157. 

IF.F.F, reports on R&D funding. Two 

reports on research and development 
funding are available in photocopy form 
from the IEEE. Electrotechnology in 
the FY1987 R&D Budget by Bill 
Harold was released by the United 
States Activities Board of the IEEE, 
concentrating on programs relating to 
electrical and electronics engineering. 

The IEEE Briefing on Federal R&D 
Funding reports on the briefing spon¬ 
sored by the IEEE on government elec¬ 
trotechnology R&D spending plans for 
the coming budget year. Contact Public 
Information, IEEE Washington Office, 
1111 19th St., NW, Suite 608, Washing¬ 
ton, DC 20036; (202) 785-0017. 

Directory of Federal Laboratory and 
Technology Resources—A Guide to Ser¬ 
vices, Facilities and Expertise, 1986- 
1987, second edition, lists federal labo¬ 
ratories and engineering and infor¬ 
mation centers available to assist U.S. 
businesses and researchers. Order PB86- 
100013/KCS, $29 plus $3 shipping and 
handling, from National Technical In¬ 
formation Service, 5285 Port Royal 
Rd., Springfield, VA 22161; (703) 
487-4600. NTIS also offers a series of 
business assessments for $500 each, con¬ 
ducted by different research organiza¬ 
tions, on manufacturing automation, 
advanced engineering composites, tele¬ 
communications, the pharmaceutical 
industry, advanced ceramics, biotech¬ 
nology/agribusiness, the computer 
industry, office automation, power gen¬ 
eration and energy storage, and the 
medical equipment industry. 

Distributed system architecture. Gerald 
Popek and Bruce Walker of Locus 
Computing have written The Locus Dis¬ 
tributed System Architecture for system 
designers familiar with the principles of 
distributed processing and for those 
people with a more general background. 
The 147-page book is available for $25 
in bookstores or from MIT Press, 28 
Carleton St., Cambridge, MA 02142; 
(617) 253-2884 for credit card orders. 
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TABLES OF CONTENTS 



Vol. 6, No. 5, May 1986 (Monthly) 
Nonmembers, $155/yr.; members, $22/yr. 


Software 

Vol. 3, No. 3, May 1986 (Bimonthly) 
Nonmembers, $108/yr.; members, $14/yr. 


<^lin TRANSACTIONS ON 

PATTERN ANALYSIS AND 
MACHINE INTELLIGENCE 

Vol. PAMI-8, No. 3, May 1986 (Bimonthly) 
Nonmembers, $125/yr.; members, $12/yr. 


• A Theory of Productivity in the Creative 
Process 

• A Bridge from Full-Function to Reduced- 
Function Workstations 

• Constraint-Based Tiled Windows 

• WHIM—The Window Handler and Input 
Manager 

• The Professional Workstation Research 
Project 

• The Realization and Application of an 
Intelligent GKS Workstation 


Guest Editor’s Introduction 
Articles 

• Display Strategies for Program 
Comprehension 

• Using Modern Design Practices to 
Upgrade Aging Software Systems 

• A Transformation-Based Paradigm for 
Software Maintenance 

• Delocalized Plans and Program 
Comprehension 



IBM TRANSACTIONS ON 

COMPUTERS 

Vol. C-35, No. 5, May 1986 (Monthly) 
Nonmembers, $160/yr.; members, $15/yr. 

• Scheduling Multiprocessor Tasks to 
Minimize Schedule Length 

• Systematic t-Error Correcting/All 


65 papers organized into 22 sessions encompass¬ 
ing the technical aspects of specifying, designing, 
implementing, and evaluating distributed com¬ 
puting systems. 572 pp. 

Order #617 

Proceedings—The 5th 
International Conference on 
Distributed Computing Systems 
Nonmembers—$66.00 Members—$33.00 


• New Classes for Parallel Complexity: A 
Study of Unification and Other Complete 
Problems for P 

• A Clustering Approximation Technique for 
Queueing Network Models with a Large 
Number of Chains 

• A Study of Pipelining in Computing Arrays 

• Improving the Performance of Buddy 
Systems 


Handling Charges Extra 
Order from IEEE Computer Society 
Order Dept. 

PO Box 80452, Worldway Postal Center 
Los Angeles, CA 90080 USA 
(714) 821-8380 


On Scheduling Tasks with a Quick 
Recovery from Failure 

Fast Search Algorithms for Associative 
Memories 

Algorithmic Aspects of MOS VLSI Switch- 
Level Simulation with Race Detection 


Editorial: Memorial Issue for K. -S. Fu 

• King-Sun Fu (1930-1985): A Biography 

• A Bibliobraphy of Published Works of the 
Late Professor King-Sun Fu 

• Ph.D. Dissertations Supervised by the 
Late Professor King-Sun Fu at Purdue 
University 

Papers 

• An Algorithm for Learning Without 
External Supervision and Its Application 
to Learning Control Systems 

• A Dynamic Programming Approach to 
Sequential Pattern Recognition 

• Learning Control Systems—Review and 
Outlook 

• Grammatical Inference: Introduction and 
Survey—Part I 

• A Tree System Approach for Fingerprint 
Pattern Recognition 

• Shape Discrimination Using Fourier 
Descriptors 

• A Step Towards Unification of Syntactic 
and Statistical Pattern Recognition 


TRANSACTIONS ON 

SOFTWARE 

ENGINEERING 

Vol. SE-12, No. 5, May 1986 (Monthly) 
Nonmembers, $160/yr.; members, $15/yr. 

Editorial 

Papers 

• The Automatic Inversion of Attribute 
Grammars 

• Efficient Decentralized Concensus 
Protocols 

• The Cloze Procedure and Software 
Comprehensibility Measurement 

• ARES: A Relational Database with the 
Capability of Performing Flexible 
Interpretation of Queries 

• Privilege Transfer and Revocation in a 
Port-Based System 

• Direct Implementation of Abstract Data 
Types from Abstract Specifications 

• Adaptive Load Sharing in Homogeneous 
Distributed Systems 
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BOOK REVIEWS 


Advanced dBase II User’s Guide — 

Adam B. Green (Prentice-Hall, Engle¬ 
wood Cliffs, N.J., 1984, 252 pp., $29) 

Adam Green is a well-known instruc¬ 
tor and industry exert on dBase II. 
Green’s books resemble his lecturing 
style—clear and concise with the right 
combination of facts, concepts, and ex¬ 
amples in an easy to read and under¬ 
stand format. Preceded by a good in¬ 
troduction to dBase II, Green’s dBase II 
User’s Guide, the Advanced dBase II 
User’s Guide is aimed at knowledgeable 
application programmers who want to 
learn how to design, build, document, 
and use software tools for dBase II. 
Software tools covered are 

(1) control of a dBase II program, 

(2) creation and use of dBase II macros, 

(3) manipulation of numbers and strings 
of characters, 

(4) date arithmetic, 

(5) use of relational model databases, 

(6) repair of damaged data files, and 

(7) manipulation of computer memory. 
The strong points of the book are 

(1) modularity of the material presented; 

(2) an excellent tutorial style; 

(3) excellent documentation of software 
tools to include pseudo-code, 
variables, program listings, special 
comments, and run-time execution 
display; 

(4) breadth of topics covered; and 

(5) generality and adaptability of soft¬ 
ware tools covered. 

Adam Green continues to live up to 
his reputation of providing good quality 
products to his customers and clients. 

Curt Hellenbrand 
Electronic Data Systems 


Processor Organization and 
Microprogramming—A Project Case 
Study —Daniel J. Nesin (Science 
Research Associates, Chicago, 1985, 

309 pp., $18.95) 

The major focus of the book is a 
detailed description of the design and 
construction of a four-bit processor and 
its associated control system using com¬ 
mercially available ICs. The author’s 
central thesis, with which I whole¬ 
heartedly concur, is that a knowledge of 
the inner workings of the hardware is 
very valuable in computer science re¬ 
gardless of one’s particular specialty and 
that hands-on experience is particularly 
helpful in driving home the theoretical 
principles. 

The book can be divided into two 
parts. The first part is primarily for 
those who lack the proper background 
to start with the design projects them¬ 
selves. There are chapters containing a 
processor architecture overview; features 
and devices used to construct processors 
such as gates, buses, and memory cells; 
and on the tying together of these de¬ 
vices into higher level units like registers, 
arrays, and ALUs. A discussion of 
system clocking is included. One chapter 
introduces the concept of a sequential 
machine, describes flip-flop operation, 
and explains a design technique for im¬ 
plementing small designs from state 
descriptions. The material is reasonably 
self-contained. How much time one 
would have to spend on it depends on 
prior exposure to hardware and digital 
principles. 

The second part of the book is a 
detailed description of the Stupidd V 
processor (Student Project in Digital 


Recently published books and new periodicals may be submitted for 
review to the book reviews editor: 

Francis P. Mathur, Mathematics Department, California State Polytechnic 
University, 3801 West Temple Avenue, Pomona, CA 91768, (714) 598-4421. 

Note: Publications reviewed in this section are not available from the 
IEEE Computer Society; they must be ordered directly from the publisher. 


Design). The design is in two parts: the 
CPU and the control system to run it. 
The processor is a four-bit op code, 
four-bit address machine with an ALU, 
registers, memory, and connections to 
the outer world, including a LED dis¬ 
play. A detailed list of IC parts is given 
with a description of their operation. 

The overall design is explained with 
instructions on connecting up all the 
parts on a board via wire wrapping. This 
part of the project could be self- 
contained if operation is controlled via 
input switches. The control system is a 
set of PROMs, which enables the con¬ 
struction of microprograms and allows 
more dynamic operation as well as more 
experience with microprogramming prin¬ 
ciples. The construction of the control 
system, however, requires access to a 
PROM programmer to write the bit pat¬ 
terns into the standard EPROMs and 
also access to an EPROM eraser for 
changing designs. 

This book could be used as a home 
study course even without building the 
projects, a sort of gedanken experiment, 
but my feeling is that it will have to be 
studied rather than read. This aspect 
takes care of itself if you actually build 
the processor. An experienced teacher 
on hand to smooth over the rough spots 
and bail out the student would be a 
definite plus. The book could be used in 
a variety of ways depending on the 
students’ backgrounds and course objec¬ 
tives. A lot of the early stuff could be 
skipped if digital design courses have 
been taken. For those lacking that back¬ 
ground, the author has done well in 
functional descriptions of device charac¬ 
teristics and IC operations. 

The chapters have good bibliographies 
and thoughtful problems to be solved. 
Numerous diagrams, many from semi¬ 
conductor catalogs, enhance the text. 
The book has a wealth of material. If 
someone asked me what I would add to 
this text, I would say more higher level 
description before the design projects. 

Overall, the book fills a useful spot in 
education and the author should be 
commended for taking the time to pub¬ 
lish it. Those wanting to get their feet 
wet with ICs and learn something about 
processors and microprogramming 
should take a look at it. 

Joseph M. Kusmiss 

IBM Academic Information Systems 
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Roster of Committees 


Standing Committees 


Audit: Hillel Ofek, Dennis Allison, Ken Anderson, 
Richard C. Jaeger, Wing N. Toy 
Awards: Ralph Preiss 
Awards Policy: Ned Komfield 
Ex-officio Members: Oscar Garcia, Ronald 
Hoelzeman, H. Troy Nagle, Martha Sloan 
Eckert-Mauchly: Ming T. Liu 
W. Wallace McDowell: John Bauer 
Technical Achievement: Arthur Pohm 
Computer Pioneer: Harry Huskey 
Computer Entrepreneur: Rex Rice 
External A wards Search: Claud Davis 
IEEE Awards Search: Marshall Yovits 
Society Search: Tse-yun Feng 
Richard E. Merwin/Dist. Service: Samuel Horvitz 
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Appreciation: Ralph Preiss (acting) 

Constitution and bylaws: Roy Russo, Edward 
Thomas, Ronald Hoelzeman, Oscar Garcia 
Elections: Wing N. Toy, H. Troy Nagle 
Finance: Joseph Urban, Helen M. Wood 
Fellows: Raymond Miller, Ming T. Liu 
Nominations: Martha Sloan, Bruce Shriver, 

Harold S. Stone, Helen M. Wood, Ronald G. 
Hoelzeman, Barry Boehm 
Operations: Roy L. Russo, J. T. Cain, John Musa, 
Joseph Urban, Martha Sloan, A1 Hoagland, 
Charles B. Silio, Roland Saam, Ray Ybaben 
East Coast Operations: Charles B. Silio, 

Helen Wood, Ken Anderson, Dennis Fife, 
Raymon P. Oberly, Paul Hazan, Ned Komfield, 
Victor Huang, James H. Aylor 
West Coast Operations: A1 Hoagland, Harut 
Barsamian, Joseph Fernandez, Michael C. 
Mulder, Gordon Padwick, Ray Ybaben, 

True Seaborn (ex-officio) 

European Operations: Roland Saam 
Computer Services Advisory: Ray Ybaben, 
Marshall Abrams, Dennis Fife, Gordon 
Padwick, Lowell Amdahl, James Barrett, 

Mary Ellen Curto, Roy L. Russo 
Personnel: Roy L. Russo, J. T. Cain, John Musa, 
Joseph Urban, Martha Sloan 
Compensation: Roy L. Russo, J. T. Cain, 

John Musa, Joseph Urban, Martha Sloan 
Planning: Edward W. Thomas, Helen M. Wood 
Ad Hoc Committees: 

European Advisory: Roland Saam 
Intersociety Cooperation: Oscar N. Garcia 
Congressional Fellow: Barry Boehm, Ming T. Liu 


Area Activities Board 


Vice President: H. Troy Nagle, Jr. 

Vice Chair: Winser E. Alexander 
Secretary: James L. Holeman 
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Region 1 ( Northeastern): Robert K. Walker 
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Harry K. Frost 
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Region 4 (Midwestern): Alicia I. Ellis 
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Region 6 (Pacific): Irving Doshay 
Region 7 (Canadian): Miguel A. Marin 
Region 8 (European Area): Roland Saam 
Region 9 (Latin America): 

Region 10 (Eastern Hemisphere): Anthony Pau 

Newsletter Editor: Charles R. Slivinsky 
Newsletter Planning: Frederick E. Petry 
Area Workshops: Anthony Pau 
Organization and Planning: James L. Holeman 
New Chapter Development: H. Troy Nagle, Jr. 
Chapter Vitality: Dennis Reinhardt 
Chapter Tutorials: Murali Varanasi 
Video Programs: Eugene R. Chenette 


Distinguished Visitors Program: Willis K. King 
Student Activities: J. Robert Heath 
Science Fair Representative: Frederick E. Petry 
Micromouse: Susan L. Rosenbaum 
New Activities: Susan L. Rosenbaum 
Finance Committee Representative: 

H. Troy Nagle, Jr. 

IEEE Student Activ. Comm. Rep.: Harriett Rigas 


Educational Activities Board 

Vice President: Glen G. Langdon, Jr. 

Vice Chair: Murali Varanasi 

Secretary/Newsletter Editor: Harry Brearley 


IEEE TAB Meeting Representative: 
Raymon P. Oberly 

CS TAB Representative: Ken Anderson 

Meetings Representatives: 

FJCC ■86: Stanley Winkler 


FJCC Steering Committee: Dick B. Simmons, 
James H. Aylor 
Compeuro: Herbert Weber 
Winter Simulation Symposium: 

Annual Simulation Symposium: 

Space Age Technology: Chester Carroll 
NCC Board: Edward Parrish 
ICCD/ICCAD Coordinating Committee: 
Peter Wolff, Sr. 


Membership and Information Activities 

Vice President: Ming T. Liu 

Jr. Past Vice President: Russell E. Theisen 

Secretary: Edward N. Shipley 


Vice President: John D. Musa 
1st Vice Chair and Vice Chair (Applications): 
Harold Carter 

Vice Chair (Hardware): Jon Butler 
Vice Chair (Software): Sallie Sheppard 


Committees: 

CSAB Accreditation: Willis K. King 
ABET Accreditation: Edward Parrish 
Continuing Education: Thomas Brubaker 
Curriculum Development: David L. Soldan 
Design Project: 

Laboratory Project: Keith Barker 
Professional Development: Richard C. Jaeger 
Associate Programs: David Hata, Lance Leventhal 
Professional Certification: Marshall Yovits 
Accreditation Guidelines: Murali Varanasi 
Planning: Harriett Rigas 

Representatives: 

ACM/CS Task Force-Precollege Ed.: 

David L. Hannum 
Computer Engr. Department Heads: 

Bill D. Carroll 

Finance Committee Representative: 

Glen G. Langdon, Jr. 

Education Rep. to COMPUTER Mag.: 

Ronald G. Hoelzeman 

ICCP: Marshall Yovits, David H. Jacobsohn 

NECC: Michael C. Mulder, Gerald L. Engel 

Conference Board Prof. Develop.: Harry Brearley 

TIE Project: David L. Hannum 

Liberal Arts Accreditation: Gerald L. Engel 

Workshops: Gerald L. Engel 

MAA Task Force: Judy Gersting 

CSAB Board: Michael C. Mulder, Taylor Booth, 

J. T. Cain, E. W. Ernst 


Conferences and Tutorials Board 


Vice President: James H. Aylor 
Vice Chair: Ken Anderson 
Secretary: 

Conferences Committee Chair: Earl Swartzlander 
Compcon Spring: Sidney Fernbach 
Compsac: Stephen Yau 

Tutorials Committee Chair: Duncan Lawrie 
Tutorial Week Orlando ’86: Murali Varanasi 
Tutorial Week Dallas ’86: Bill Buckles 
Tutorial Week Washington ’86: Ming T. Liu, 
Tse-yun Feng 

Tutorial Week Los Angeles ’86: 

Masahiro Tsuchiya 
Tutorial Week Boston ’86: Ted Bonn 
Tutorial Week RTP '86: H. Troy Nagle 
Tutorial Week San Francisco '86: Sidney Fembach 
Tutorial Week Austin '86: V. Thomas Rhyne 

Finance Chair: Barry Johnson 
Proposal Review Chair: Dharma Agrawal 
Special Projects Chair: Marshall Abrams 


Admissions Committee: Henry Chuang 
Membership Committee: Walter H. Kohler 
Public Policy Committee: Ned Komfield 
Volunteer Development Committee: 

Masahiro Tsuchiya 

Members-at-Large: David Cohen, Herbert Weber, 
Chuan-lin Wu, Akihiko Yamada, Marshall Yovits 


Publications Board 

Vice President: J. T. Cain 
Vice Chair: Richard C. Jaeger 
Secretary: Willis K. King 

Editors-in-Chief: 

Computer: Michael C. Mulder 
Computer Graphics <S Applications: 

Lansing Hatfield 

Design & Test: Vishwani Agrawal 
Expert: David Pessel 
Micro: James Farrell 
Software: Brace Shriver 

Transactions on Computers: Tse-yun Feng (6/86); 
Ming T. Liu (6/88) 

Transactions on PAMI: Steven L. Tanimoto 
Transactions on Soft. Eng.: C. V. Ramamoorthy 
C. S. Press: Bill D. Carroll 

Committees (Chairs Listed First) : 

Magazine Advisory: Dennis R. Allison, Michael C. 
Mulder, Lansing Hatfield, Vishwani Agrawal, 
David Pessel, James Farrell, Bruce Shriver, 
Dharma Agrawal, True Seaborn, Christina 
Champion, Michael Koehler 
Transactions Advisory: Duncan H. Lawrie, Tse- 
yun Feng, C. V. Ramamoorthy, Ming T. Liu, 
Steven L. Tanimoto, Taylor Booth 
Computer Society Press Advisory: Richard C. 
Jaeger, M. Abrams, D. Agrawal, Bill D. 

Carroll, M. Varanasi, Chip Stockton, S. 
Rosenbaum 

Publications Planning: Michael Evangelist, 

W. Sacchi, Jack Grimes 
Rules and Practices: Dharma Agrawal 

IEEE Publications Board Rep.: Bruce Shriver, 
Theo Pavlidis 

IEEE TAB Periodicals Comm. Rep.: J. T. Cain, 
Sam Horvitz 

Finance Committee Representative: J. T. Cain, 
Richard C. Jaeger 

CS TAB Liaison: Norman Schneidewind 

Members-at-Large: Ronald G. Hoelzeman, 

Jack Lipovski 


Technical Activities Board 




































CALL FOR PAPERS 


Call for papers for Computer 


Computer magazine seeks articles that 
cover the state of the art and important 
new developments in computer science, 
technology, and applications. Aimed at a 
broad audience with diverse interests and 
experience, Computer usually publishes 
surveys or tutorials that facilitate the 
transfer of technology from university to 
industry, from research to applications, 
and across specialized fields. Submit six 
copies of the manuscript, including illus¬ 
trations, references, and authors’ biogra¬ 
phies, to the editor-in-chief: 

• Michael C. Mulder 
Applied Research 
University of Portland 
Portland, OR 97203 
Phone (503) 283-7433 

Computer also seeks articles on topics 
relevant to upcoming special issues. Sub¬ 
mit six copies of the manuscript directly 
to the guest editor: 

• Computers for Artificial Intelligence 
Applications: Submit by May 15, 


1986, to Benjamin Wah, Dept, of 
ECE and the Coordinated Science 
Lab, The University of Illinois, 
Urbana, IL 61801. 


Lastly, Computer seeks special issue pro¬ 
posals and articles in the following topic 
areas: 

• microprocessor architectures 

• networking and distributed 
computing 

• computer-integrated manufacturing 

• software quality assurance 

• programming environments 

Prospective guest editors and authors 
should submit proposals and articles 
directly to Michael Mulder. 

An authors’ information sheet can be ob¬ 
tained from Michael Mulder at the above 
address or from the IEEE Computer So¬ 
ciety West Coast Office, 10662 Los Va- 
queros Circle, Los Alamitos, CA 90720; 
(714) 821-8380. 


Applied Robotics and Design Automation 
Conference: November 10-12, 1986, St. 

Louis, Missouri. Submit a one-page abstract 
by May 15, 1986, to A. H. Soni, School of 
Mechanical and Aerospace Engineering, 
Oklahoma State University, Stillwater, OK 
74078; (405) 624-5900. 

Second Aerospace Computer Security Con¬ 
ference: Protecting Intellectual Property 
(AIAA, ASIS, DoD Computer Institute): De¬ 
cember 2-4, 1986, Washington DC. Submit 
three copies of unclassified abstracts of 500 to 
1000 words by May 20, 1986, to Stephen 
Walker, Trusted Information Systems, Inc., 
PO Box 45, Glenwood, MD 21738. Proposals 


for panel discussions and tutorials are also 
sought. Submit proposals for panel discus¬ 
sions to Stephen Walker and proposals for 
tutorials to J. Chris Perry, Mitre Corp., 1820 
Dolley Madison Blvd., McLean, VA 22102. 
Classified sessions at the SECRET level are 
planned. Abstracts/proposals should be 
cleared with the author’s security officer 
before submission. 

CAR-87, Second International 
Conference on Computer-Assisted 
Radiology: July 1-4, 1987, Berlin, West Ger¬ 
many. Submit four copies of a 200-to-500- 
word abstract (including six keywords) by 
May 31, 1986, to AMK Berlin, Messedamm 


Calls are listed according to submittal deadlines. Conferences that the Computer Socie¬ 
ty participates in or sponsors are indicated by the IEEE Computer Society logo; others 
of interest to our readers are also included. For inclusion in “Call for Papers,” submit 
information six weeks before the month of publication (e.g., for the August 1986 issue, 
send information for receipt by June 15, 1986) to COMPUTER, 10662 Los Vaqueros Cir¬ 
cle, Los Alamitos, CA 90720. 


22, D-1000 Berlin 19, West Germany; phone 
(030) 3038-3629 or 3038-3220; telex 182890 
amkcd. 

Japan Display 86, The Sixth International 
Display Research Conference (ITE, SID): 
September 30-October 2, 1986, Tokyo, 

Japan. Submit three copies of both a 35-word 
abstract and a summary by May 31, 1986, to 
Shunsuke Kobayashi, c/o Secretariat of 
Japan Display 86, Japan Convention Ser¬ 
vices, Inc., Nippon Press Center Bldg., 2-2-1, 
Uchisaiwai-cho, Chiyoda-ku, Tokyo 100, 
Japan; phone 03-508-1211; telex J33104 JCS 
TOKYO. Post-deadline papers that describe 
research developments and are suitable for 
10-minute presentations are also sought. Sub¬ 
mit camera-ready copy by September 1, 1986. 

Sixth Conference on Foundations of Software 
Technology and Theoretical Computer 
Science: December 18-20, 1986, New Delhi, 
India. Submit four copies of papers by May 
31, 1986, to K. V. Nori, TRDDC, 1 
Mangaldas Rd., Pune, 411001, India. 


1986 Workshop on Interactive 3-D Graphics 

(ACM): October 22-24, 1986, Chapel Hill, 
North Carolina. Submit five copies of an ex¬ 
tended abstract (two to three pages long) by 
June 1,1986, to Frank C. Crow (Xerox 
PARC) or Stephen M. Pizer, Dept, of Com¬ 
puter Science, New West Hall 035A, The 
University of North Carolina, Chapel Hill, 

NC 27514. 

Proceedings of the IEEE: Papers are sought 
for a special issue scheduled for publication in 
September 1987; it will focus on “Hardware 
and Software of Digital Signal Processing.” 
Submit summaries by June 1, 1986, to Sanjit 
K. Mitra, Dept, of Electrical and Computer 
Engineering, University of California, Santa 
Barbara, CA 93106; (805) 961-3957 or Kalyan 
Mondal, AT&T Bell Laboratories, Room 
2F-223, 1247 S. Cedar Crest Blvd., Allen¬ 
town, PA 18103; (215) 770-3643. 

Symposium on Human Factors in Manage¬ 
ment Information Systems: October 8-10, 

1986, College Station, Texas. Send three 
copies of complete paper (20 pages maximum) 
and abstract (150 words maximum) by June 
1, 1986, to Jane M. Carey, Dept, of Business 
Analysis, Texas A&M University, College 
Station, TX 77843. 


Third International Software Process 
Workshop: November 17-19, 1986, 
Breckenridge, Colorado. Submit position 
paper (three pages maximum) by June 1, 

1986, to either Robert M. Balzer, Information 
Sciences Institute, 4676 Admiralty Way, Suite 
1001, Marina del Rey, CA 90292 or Mark 
Dowson, Imperial Software Technology, 60 
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Albert Ct., Prince Consort Rd., London SW7 
2BH, UK. Workshop limited to 30 people. 

1986 ACM Sigcpr International Conference 
on New Careers in Computing: October 
16-17, 1986, Calgary, Alberta, Canada. 
Technical, survey, and position papers are 
sought. Send two copies of the complete 
paper (including abstract) by June 2, 1986, to 
Raymond McLeod, Jr., Dept, of Business 
Analysis and Research, College of Business 
Administration, Texas A&M University, Col¬ 
lege Station, TX 77843. 


plinary Solutions to CAD Problems,” are 
sought. Submit five copies of the complete 
paper (20 pages maximum) for receipt by 
June 30, 1986, to Mario Barbacci, Software 
Engineering Institute, Carnegie-Mellon Uni¬ 
versity, Pittsburgh, PA 15213; (412) 268-7704. 

Compeuro 87, International Conference 
on VLSI and Computers: May 11-15, 
1987, Hamburg, West Germany. Submit sum¬ 
maries (100 words maximum) by July 1, 1986, 
to W. E. Proebster, c/o IBM, PO Box 80 08 
80, D-7000 Stuttgart 80, West Germany. 


Second Tesseral Workshop: September 22-23, 
1986, Reading, England. Send abstract by 
June 4, 1986, to Sarah Bell, NUTIS, Universi¬ 
ty of Reading, Whiteknights, Reading RG6 
2AH, UK. 

£jji IEEE Expert: Articles are solicited for a 
7S7 special issue on building intelligence 
into the software life cycle. The topic includes 
AI techniques and tools for developing and 
maintaining software systems, and software 
project management. Submitted materials 
typically (1) range from 15 to 30 double¬ 
spaced, typewritten pages (those at the lower 
end of this page budget are preferred); (2) 
have 1 '/2-inch margins; and (3) have no more 
than 10 references. Submit six copies of the 
article by June 15, 1986, to Joseph E. Urban, 
Center for Advanced Computer Studies, 
University of Southwestern Louisiana, PO 
Box 44330, Lafayette, LA 70504; (318) 
231-6304. 


£27, IEEE Micro: Articles are solicited for a 
7*7 special issue on multiprocessing that is 
scheduled for publication in October 1986. 
Submit them by June 15, 1986, to James J. 
Farrell III, VLSI Technology, Inc., 10220 S. 
51st St., Phoenix, AZ 85044. Author guide¬ 
lines may be obtained from James Farrell or 
from the IEEE Computer Society West Coast 
Office, 10662 Los Vaqueros Circle, Los 
Alamitos, CA 90720-2578; (714) 821-8380. 


Joint Conference: Melecon 87, Mediterranean 
Electrotechnical Conference, and 34th Con¬ 
gress on Electronics (IEEE, RIENA): March 
24-26, 1987, Rome, Italy. Submit three copies 
of a 200-word abstract by June 15, 1986, to 
Melecon 87 and 34th Congress on Electronics, 
Secretariat, c/o RIENA, Via Crescenzio 9, 
00193 Rome, Italy. The IEEE Region 8 stu¬ 
dent paper contest will be held during the 
conference. 


£27 Third International Conference on Data 
7*7 Engineering: February 2-6, 1987, Los 
Angeles, California. Submit four copies of 
papers by June 15, 1986, to IEEE Computer 
Society, 1730 Massachusetts Ave., NW, 
Washington DC 20036-1903; (202) 371-0101. 
Proposals for tutorials are also sought. Sub¬ 
mit them by May 15, 1986, to James A. Lar¬ 
son, Honeywell Computer Sciences Center, 
1000 Boone Ave. North, Golden Valley, MN 
55427; (612)541-6836. 

CHDL-87, Eighth International Symposium 
on Computer Hardware Description Lan¬ 
guages and Their Applications (IFIP): April 
27-29, 1987, Amsterdam, The Netherlands. 
Papers on the conference theme, “Multidisci¬ 


Fifth International Modal Analysis Con¬ 
ference: April 6-9, 1987, London, England. 
Send an abstract (200 words maximum) and a 
submission form (available from the Gradu¬ 
ate and Continuing Studies Office) by July 1, 
1986, to Dominick J. DeMichele, Union Col¬ 
lege, Graduate & Continuing Studies, Wells 
House, 1 Union Ave., Schenectady, NY 
12308-2363; (518) 370-6288. 

International Switching Symposium (IEEE): 

March 15-21, 1987, Phoenix, Arizona. Sub¬ 
mit six copies of papers (five pages maximum, 
including a 500-word abstract) by July 1, 

1986, to Frank Young, Mountain Bell 
Telephone Co., 3033 N. Third St., Room 901, 
Phoenix, AZ 85012. 

MCC Interdisciplinary Conference on 
Computer-Supported Cooperative Work: De¬ 
cember 3-5, 1986, Austin, Texas. Submit six 
copies of an extended abstract (10 to 15 
pages) by July 1, 1986, to Irene Greif, MIT 
Lab for Computer Science, 545 Technology 
Square, Cambridge, MA 02139. 


Sixth Annual Phoenix Conference on Com¬ 
puters and Communications (IEEE): Feb¬ 
ruary 25-27, 1987, Scottsdale, Arizona. Sub¬ 
mit five copies of the paper (5000 words long; 
include a 200-to-300 word abstract) by July 3, 
1986, to Forouzan Golshani, Dept, of Com¬ 
puter Science, Arizona State University, 
Tempe, AZ 85287; (602) 965-2855. 


£27, Compcon Spring 87: February 23-26, 
7*7 i987 j s an Francisco, California. This 
conference provides a broad-based technical 
update on the computer field. Persons in¬ 
terested in making technical presentations 
should submit four copies of a proposal rang¬ 
ing from 500 words to a draft manuscript for 
the digest of conference papers. Persons in¬ 
terested in organizing 90-minute sessions in¬ 
volving three speakers should send a descrip¬ 
tion of the proposed session theme and a list 
of suggested speakers. Submit materials in 
both categories by July 11, 1986, to Glen G. 
Langdon, Jr., IBM Dept. K54-802, 650 Harry 
Rd., San Jose, CA 95120-6099; (408) 
927-1818. 


£27, Fourth International Workshop on 
7*7 Software Specification and Design 
(ACM, AFCET, Agence de l’lnformatique, 
Alvey Directorate, LCRST-Japan): April 3-4, 
1987, Monterey, California. Submit four 
copies of position papers by July 14,1986, to 
M. T. Harandi, Dept, of Computer Science, 
University of Illinois at Urbana-Champaign, 
1304 W. Springfield, Urbana, IL 61801. 


Roster of Committees 


(continued from p. 103) 


Society Representatives 

Society Level: Roy L. Russo 
AFIPS Representatives: 

Directors: Stanley Winkler, Tse-yun Feng, 

Executive Committee: Tse Feng 
Admissions Committee: Michael C. Mulder 
Nominations Committee: Martha Sloan 
NCC Board: Edward Parrish 
Education Committee: Taylor L. Booth 
Finance Committee: Joseph Urban 
Government Activities: 

Public Policy Comm. Liaison: 

Constitution /Bylaws Committee: 

Dick B. Simmons 


IEEE: Ronald Hoelzeman 
IEEE TAB/USAB Engineering 
R&D Committee: 

Paul Hazan 

IEEE TAB/USAB Defense R&D Committee: 
Paul Hazan 


Membership & Information: Ming T. Liu 
IEEE TAB/USAB Communications and 
Information Policy Committee: 

Marshall Yovits, Claud Davis 
The Computer Museum: Ted Bonn 


Conferences: James H. Aylor 
Fall Joint Computer Conference: Stanley Winkler 
Fall Joint Computer Conference Steering 

Dick B. Simmons, James H. Aylor 
Annual Simulation Symposium: 

Winter Simulation Symposium: 

ICCAD/ICCD Coord. Committee: Peter K. 
Wolff, Sr., Harut Barsamian, Charles Radke, 
Arnold Goldfein, Paul Horstmann 
Compeuro: Thomas Williams, Herbert Weber, 
Paul Borrill 


Educational Activities: 

Glen G. Langdon, Jr. 

Computing Sciences: 

Accreditation Board: J.T. Cain (VP), Taylor L. 
Booth (P. Pres.), Edward W. Ernst, Michael C. 
Mulder, Gerald Engel (Alt.), Lansing Hatfield 
(Alt.) 

Institute for Certification of Computer 
Professionals: 

Marshall Yovits, David H. Jacobsohn 


Publications: J. T. Cain 
Steering Committee, Journal on Lightwave 
Technology: 


Technical Activities: John Musa 
IEEE Council on Robotics and Automation: 

Wesley E. Snyder, Eric Grimson 
IEEE Solid State Circuits Council: 

Earl Swartzlander, Sol Triebwasser 
Internationa! Association for Pattern Recognition: 
Theo Pavlidis, J.K. Agrawal, Herbert Freeman 


Standards: Helen M. Wood 
IEEE Standards Board: Helen M. Wood 
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1986 TUTORIAL WEEK PROGRAMS 

■ Is your professional continuing education keeping pace with the needs 
of tomorrow? 

■ The Tutorial Week Programs are especially designed to assistyou. 

■ By popular demand, we have expanded our Tutorial Week Programs 
from three to eight. 

■ Don't be left out — prepare yourself for the futurel 


TUTORIAL WEEK Washington '86 June 9 - 13,1986 


Track I 

Microprocessor Architecture: 
Principles & Examples 
Semicustom Design of VLSI Circuits 
Systolic Array Processing 
Adv. Microprocessors & High-Level 
Language Computer Architecture 
Survlvable Computing Systems 


Track II 

Distributed Systems Design 
Distributed Systems: Specification, 
Design and Verification 
Synchronization, Resource Allocation 
& Broadcasting In Distributed 
Systems 

Principles of Message-Based 
Operating Systems 
Distributed Database Applications 


in Mike Liu, Ohio St 


eUnfv. 


Track III 

Data Communications 
Digital PBX: Integrated Volce/Data- 
Concepts, Technology and Products 
LANs, PC Networks and Workstations 
Local Computer Networks: 

Software Applications 
Performance Analysis of Local Area 
Networks 


TUTORIAL WEEK Los Angeles 86 August 18 - 22 ,1986 

Track I Track II 

Knowledge-Based Systems Computer Communlatfon Networks— 

Advanced Topics In Expert Systems Design and Analysis 

Prolog and Knowledge Information Distributed Systems 

Processing Small Computer Local Area Networks 

Knowledge-Based Systems for Soft- 


Computers for Al Applications 


Computer Security 


Chain Masahlro Tsuchlya 
Track III 

Interactive Software Development 


Engineering 
Software Testing 

Expert Systems and Intelligent Agents 


TUTORIAL WEEK Boston '86 


Track I 

Software Quality 
Amu ranee—A Practical 


Configuration 
iment I 

Configuration 


Software Management 


Ada Environments 


Track II 

Tools for Building Expert 
Systems Development 
PROLOG and Language 
Processor Prototyping 
The Management of 
Expert System 


September 8-12,1986 

Track III 

Networking PCs 
Fault-Tolerant Distributed 
Operating Systems 
Performance Analysis of 
Local Area Networks 
Tools for Developers of 
Distributed Software 
Systems 

Query Processing In 
Relational Database 
Management Systems 


Chain Ted Bonn 
Track IV 

Compilers for Super- 


Vector Processing 
Work Station Technology 
Semi-Custom Design of 


See future issues of Computer Magazine for details on the following events: 
_ w/ r ^ Research Triangle Park '86, October 17-20,1986 

TW San Francisco '86, (previously known as TW West), November 17-21,1986 
TW Austin '86, December 15-19,1986 

For further Information return this form to: 

Director of Tutorials, IEEE Computer Society 

1730 Massachusetts Avenue, NW, Washington, DC 20036-1903 

Telephone: (202) 371-0101 

Name: ______ 

Organization : ~ '■V--- v- :; ' ^ -v ; ' ; y : ' : ■: ' :: ' . 

Address: ___ 


Clly/State/Zip/Country: 



» the INSTITUTE OF ELECTRICAL 
vC AND ELECTRONICS ENGINEERS, INC. 


IEEE COMPUTER SOCIETY 











CALENDAR 


May 1986 


Semicon/West 86, May 19-22, San Mateo, 
California. Contact Semiconductor Equip¬ 
ment and Materials Institute, Inc., 625 Ellis 
St., Suite 212, Mountain View, CA 94043; 
(415)964-5111. 

Sixth International Conference on 
Distributed Computing Systems, May 

19- 23, Cambridge, Massachusetts. Contact 
Ming T. Liu, Ohio State University CIS, 2036 
Neil Ave., Columbus, OH 43210; (614) 
422-1837. 

CAPE-86, Second International Conference 
on Computer Applications in Production and 
Engineering (IFAC, IFIP, IFORS), May 

20- 23, Copenhagen, Denmark. Contact 
CAPE-86, DIS Congress Service, 48, Linde 
Alle, DK-2720 Vanlose/Copenhagen, Den¬ 
mark. 

International Workshop on Visual Aids in 
Programming: Cognitive Aspects of Visual 
Aids in Problem Solving with Computers and 
the Design of User Interfaces (ACM), May 
20-23, Passau, West Germany, and Schar- 
ding, Austria. Contact Osterreichische Com¬ 
puter Gesellschaft, Wollzeile 1-3, A-1010 
Vienna, Austria; phone 0222/52 02 35. 

Sococo 86, IFAC/IFIP Symposium on Soft¬ 
ware for Computer Control, May 20-23, 

Graz, Austria. Contact Mrs. R. Hammer, IIG 
SchieBstattgasse 4a, A-8010 Graz, Austria. 

CSCSI-86, Sixth National Conference of the 
Canadian Society for Computational Studies 
of Intelligence, May 21-23, Montreal, 

Canada. Contact Bill Havens, University of 
British Columbia, Dept, of Computer 
Science, Vancouver, British Columbia V6T 
1W5, Canada. 

Automach Australia (SME), May 26-30, 

Sydney, Australia. Contact Society of 
Manufacturing Engineers, One SME Dr., 

PO Box 930, Dearborn, MI 48121; (313) 
271-1500. 

Graphics Interface 86, May 26-30, Van¬ 
couver, British Columbia, Canada. Contact 
Gunther Schrack, University of British Col¬ 
umbia, Electrical Engineering Dept., Van¬ 
couver, British Columbia V6T 1W5, Canada; 
phone (604) 228-2326. 


SEAIJS-86, Sino-European Artificial In¬ 
telligence Joint Seminar, May 26-30 (Shen¬ 
zhen City) and June 1-6 (Beijing), China. 
Contact J. M. Richards, The Turing Institute, 
George House, 36 N. Hanover St., Glasgow 
G1 2AD, UK. 

Third Conference on Software 
Engineering (ACM, AFCET, Agence de 
I’lnformatique, INRIA), May 26-30, Ver¬ 
sailles, France. Contact Marie-France 
Kalogera, AFCET Informatique, 156 Blvd. 
Pereire, 75017 Paris, France. 

Vision Interface 86, May 26-30, Vancouver, 
British Columbia, Canada. Contact R. J. 
Woodham, University of British Columbia, 
Dept, of Computer Science, Vancouver, 

British Columbia V6T 1W5, Canada; phone 
(604) 228-4368 or M. Goldberg, University of 
Ottawa, Dept, of Electrical Engineering, Ot¬ 
tawa KIN 6N5, Canada; phone (613) 

231-2495. 

Integrating Computing Into the Higher 
Education Curriculum (Educom), May 27-28, 

Durham, North Carolina. Contact Educom, 
PO Box 364, Princeton, NJ 08540. 

1986 IEEE International Symposium on 
75? Multiple-Valued Logic, May 27-29, 

Blacksburg, Virginia. Contact Joseph G. 
Tront, Virginia Polytechnic Institute and 
State University, Dept, of Electrical Engineer¬ 
ing, Blacksburg, VA 24061; (703) 961-5067. 

ACM Sigmod 86, International Conference 
on Management of Data, May 28-30, Ar¬ 
lington, Virginia. Contact Carlo Zaniolo, 
MCC, 9430 Research Blvd., Echelon Bldg. 

No. 1, Austin, TX 78759. 

18th Annual ACM Sigact Symposium on 
Theory of Computing, May 28-30, Berkeley, 
California. Contact Eugene L. Lawler, Com¬ 
puter Science Division, Evans Hall, University 
of California at Berkeley, Berkeley, CA 
94720; (415) 642-4019. 

1986 VLSI Technology Symposium (IEEE), 
May 28-30, San Diego, California. Contact 
Lewis Terman, IBM T.J. Watson Research 
Center, PO Box 218, Yorktown Heights, NY 
10598; (914) 945-2029. 

Performance 86 and ACM Sigmetrics 86, 
Joint Conference on Computer Performance 
Modelling, Measurement, and Evaluation 
(ACM, IFIP, IRISA/INRIA), May 28-30 


Conferences that the Computer Society participates in or sponsors are indicated by the IEEE 
Computer Society logo; other conferences of interest to our readers are also included. For in¬ 
clusion in Calendar, submit information six weeks before the month of publication (e.g., for 
the August 1986 issue, send information for receipt by June 15,1986) to COMPUTER, 10662 
Los Vaqueros Circle, Los Alamitos, CA 90720. 


(tutorials will be offered May 27), Raleigh, 
North Carolina. Contact Harry G. Perros, 
North Carolina State University, Raleigh, NC 
27695; (919) 737-2858. 


June 1986 


Networks 86, Third International Network 
Planning Symposium (IEEE), June 1-6, Tar¬ 
pon Springs, Florida. Contact Warren 
Falconer, AT&T Bell Laboratories, 

Crawfords Corner Rd., Holmdel, NJ 07733; 
(201) 949-1500. 

Second Symposium on Computational 
Geometry (ACM), June 2-4, Yorktown 
Heights, New York. Contact Alok Aggarwal, 
IBM T.J. Watson Research Center, PO Box 
218, Yorktown Heights, NY 10598; (914) 
945-2027. 

1986 IEEE Solid-State Sensor Conference, 
June 2-5, Baltimore, Maryland. Contact Kurt 
Petersen, 6244 Solomon Court, San Jose, CA 
95123; (408) 224-8818. 

Structure in Complexity Theory Con- 
75? ference (ACM, NSF), June 2-5, 
Berkeley, California. Contact Alan L. 

Selman, Computer Science Dept., Iowa State 
University, Ames, IA 50011; (515) 292-7755. 

13th Annual International Conference 
75? on Computer Architecture (ACM, IP- 
SJ), June 2-5, Tokyo, Japan. Contact Hideo 
Aiso, Dept, of Electrical Engineering, Keio 
University, 3-14-1 Hiyoshi, Kohohu-ku, 
Yokohama 223, Japan; phone 044-63-1141. 

Vision 86, International Conference and Ex¬ 
position on Applied Machine Vision (SME), 
June 2-5, Detroit, Michigan. Contact SME, 1 
SME Dr., PO Box 930, Dearborn, MI 48121; 
(313)271-1500. 

NECC-86, Seventh National Educa- 
75? tional Computing Conference (ACM, 
SCS), June 4-6, San Diego, California. Con¬ 
tact Susan M. Zgliczynski, University of San 
Diego, School of Education, Alcala Park, 

San Diego, CA 92110; (619) 293-4538. 

NATO Advanced Study Institute on Pattern 
Recognition Theory and Applications, June 
8-20, Spa-Balmoral, Belgium. Contact Pierre 
A. Devijver, Philips Research Laboratory, 
Ave. Van Becelaere 2, Box 8, B-1170, 

Brussels, Belgium or Josef V. Kittler, SERC 
Rutherford Appleton Laboratory, Chilton, 
Didcot OX11 0QX, UK. 

ACM Sigdoc Fifth International Conference 
on System Documentation, June 9-11, Toron¬ 
to, Canada. Contact Diana Patterson, 
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Sysdoc, 41 Britain St., Suite 300, Toronto, 
Ontario M5A 1R7, Canada. 

19th Annual Conference of the Association of 
Small Computer Users in Education, June 
9-11, Myrtle Beach, South Carolina. Contact 
Jack Cundiff, Horry-Georgetown Technical 
College, Conway, SC 29526. 

IEEE Computer Society Tutorial Week 
^ Washington 86, June 9-13, Arlington, 
Virginia. Contact Tutorial Week Washington, 
IEEE Computer Society, 1730 Massachusetts 
Ave., NW, Washington DC 20036-1903; (202) 
371-0101; TWX 7108250437 IEEECOMPSO. 

First China-USA International Conference on 
Graph Theory with Its Applications, June 

9- 20, Jinan, Shandong Province, China. Con¬ 
tact Esther Weaver, John Mulcahy Hall 340, 
Dept, of Computer and Information Science, 
Fordham University, Bronx, NY 10458-4598; 
(212) 579-2589. 

Fourth Annual Comdex International, June 

10- 12, Nice, France. Contact Interface 
Group, Inc., 300 First Ave., Needham, MA 
02194; (617) 449-6600. 

Summer 1986 Usenix Technical Conference 
and Exhibition, June 10-13, Atlanta, Georgia. 
Contact Usenix Association, Conference Of¬ 
fice 16951 Pacific Coast Hwy., PO Box 385, 
Sunset Beach, CA 90742; (213) 592-3243. 

1986 Rochester Forth Conference, June 
10-14, Rochester, New York. Contact 
Lawrence Forsley, Laboratory for Laser 
Energetics, 250 E. River Rd„ Rochester, NY 
14623-1299; (716)275-5101. 

Knowledge-based Signal Processing Special 
Institute, June 11-20, North Dartmouth, 
Massachusetts. Contact C. H. Chen, Dept, of 
Electrical and Computer Engineering, 
Southeastern Massachusetts University, North 
Dartmouth, MA 02747; (617) 999-8475. 

25th Annual Technical Symposium of the 
Washington DC Chapter of the ACM (NBS), 
June 12-13, Gaithersburg, Maryland. Contact 
Richard Muller, ASCI, 14411 Pebble Hill 
Lane, Gaithersburg, MD 20878; (301) 

424-8515. 


First Annual Industrial Ergonomics and Safe¬ 
ty Conference, June 12-14, Louisville, Ken¬ 
tucky. Contact W. Karwowski, Dept, of In¬ 
dustrial Engineering, University of Louisville, 
Louisville, KY 40292; (502) 588-6342. 

International Workshop in Advanced Pro¬ 
gramming Environments (IFIP), June 16-18, 

Trondheim, Norway. Contact Reidar Con- 
radi, Division of Computer Science, Technical 
University of Norway, N-7034 Trondheim, 
Norway. 


gi Symposium on Logic in Computer 
Science (ACM), June 16-18, Cam¬ 
bridge, Massachusetts. Contact Askok K. 
Chandra, IBM T.J. Watson Research Center, 
PO Box 218, Yorktown Heights, NY 10598; 
(914) 945-1752. 


gi NCC-86,1986 National Computer Con- 
^ ference (ACM, AFIPS, DPMA, SCS), 
June 16-19, Las Vegas, Nevada. Contact 
AFIPS, 1899 Preston White Dr„ Reston, VA 
22091; (703) 620-8900. 

1986 American Control Conference (AIAA, 
AIChE, ASME, IEEE, ISA, SCS), June 

18- 20, Seattle, Washington. Contact Edwin 
B. Stear, The Washington Technology 
Center, 376 Loew Hall, FH-10, The Universi¬ 
ty of Washington, Seattle, WA 98195; (206) 
545-1920. 

1986 AIC Interim Meeting on Color in 
Computer-Generated Displays (ACM), June 

19- 20, Toronto, Canada. Contact Peter K. 
Kaiser, Dept, of Psychology, York Universi¬ 
ty, North York, Ontario M3J 1P3, Canada; 
phone (416) 667-6335. 

ICC-86, International Conference on Com¬ 
munications (IEEE), June 22-25, Toronto, 
Canada. Contact Hugh J. Swain, Andrew 
Antenna, Ltd., 606 Beech St„ Whitby, On¬ 
tario LIN 5S2, Canada; phone (416) 

668-3348. 

gji Computer Vision and Pattern Recog- 
nition, June 22-26, Miami Beach, 
Florida. Contact Linda Shapiro, MVI, 325 E. 
Eisenhower, Ann Arbor, MI 48104; (313) 
996-8033. 

94th Annual Conference of the American 
Society for Engineering Education, June 
22-26, Cincinnati, Ohio. Contact Barbara L. 
Ramey, ASEE, Member Activities, 11 Du¬ 
pont Circle, Suite 200, Washington DC 
20036; (202) 293-7080. 

Sigplan 86, Symposium on Compiler Con¬ 
struction (ACM), June 23-27, Palo Alto, 
California. Contact John R. Sopka, Digital 
Equipment Corp., ZKO 2-1/P05, 110 Spit 
Brook Rd., Nashua, NH 03062. 

g^ IEEE Westex 86, June 24-26, Ana- 
heim, California. Contact Gerhard L. 
Hollander, Hollander Associates, Box 2276, 
Fullerton, CA 92633; (714) 879-9005 or 
Russell Bennett, PO Box 2111, Fullerton, CA 
92633-0111; (714)768-3506. 

International Joint Conference on CAD and 
Robotics in Architecture and Construction, 
June 25-27, Marseilles, France. Contact Vi- 
viane Bernadac, IIRIAM/2, Rue Henri- 
Barbusse/CMCI/13241, Marseilles, Cedex 1, 
France. 


gi Workshop on Visual Languages, June 
25-27, Dallas, Texas. Contact Robert R. 
Korfhage, Southern Methodist University, 
Dept, of Computer Science, School of 
Engineering and Applied Science, Dallas, TX 
75275; (214) 692-3083. 


gi 23rd ACM/IEEE Design Automation 
vS? Conference, June 29-July 2, Las Vegas, 
Nevada. Contact Pat Pistilli, MP Associates, 
7366 Old Mill Trail, Suite 101; Boulder, CO 
80301; (303) 530-4562. 


International Summer Institute: State of the 
Art in Computer Graphics —Techniques and 


Applications (ACM, BCS, Computer 
Graphics Society of Japan), June 29-July 4, 

Stirling, Scotland. Contact David Rogers, 
Aerospace Engineering CAD/ICG Group, US 
Naval Academy, Annapolis, MD 21402 or 
Frances Johnson, University of Leeds, UK; 
phone 44-532-459944. 

Seventh European Workshop on Applications 
and Theory of Petri Nets (AFCET, AICA, 
BCS, EATCS, GI), June 30-July 2, Oxford, 
England. Contact M. Diaz, LAAS du CNRS, 
7 Ave. du Colonel Roche, F-31077 Toulouse 
Cedex, France. 

Workshop on Document Generation Prin¬ 
ciples (ACM), June 30-July 2, Snowbird, 

Utah. Contact Michael Lesk, Bellcore, Room 
2A385, 435 South St., Morristown, NJ 07960; 
(201) 829-4070. 

Fourth IF AC Symposium on Control of 
Distributed Parameter Systems (AACC, 
IEEE), June 30-July 3, Pasadena, California. 
Contact G. Rodriguez, Jet Propulsion 
Laboratory, Mail Station 198-326, 4800 Oak 
Grove Dr., Pasadena, CA 91109; (818) 
354-4057. 
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gj> FTCS-16, 16th International Sym- 
posium on Fault-Tolerant Computing 
(IFIP), July 1-3, Vienna, Austria. Contact H. 
Kopetz, Institut fur Praktische Informatik, 
Technische Universitat Wien, GubhausstraBe 
30/180, A-1040 Vienna, Austria; phone 
(0222) 56-01. 

International Conference on Systolic Arrays 
(IEEE), July 2-4, Oxford, England. Contact 
Will Moore, Oxford University, Dept, of 
Engineering Science, Park Rd., Oxford, OX1 
3PJ, UK; phone 0865 59988; telex 83295 
NUCLOX G. 

Second International Conference on Conduc¬ 
tion and Breakdown in Solid Dielectrics 
(IEEE), July 7-10, Erlangen, West Germany. 
Contact P. Fischer, Siemens AG, Abt. ZFE 
CWV 2, PO Box 3240, 8520 Erlangen, West 
Germany; phone 09131-75690. 

APL-86 (ACM, BCS), July 7-11, Manchester, 
England. Contact BISL Conference Dept., 
The British Computer Society, 13 Mansfield 
St., London W1M 0BP, UK. 

Compass 86, Computer Assurance Con¬ 
ference-Systems Integrity, Process Security 
and Safety (IEEE), July 7-11, Washington 
DC. Contact Albert W. Friend, Compass, 

PO Box 3815, Gaithersburg, MD 20878. 

gi International Optical Computing Con- 
ference, July 7-11, Shoresh, Israel. 
Contact Joseph Shamir, Dept, of Electrical 
Engineering, Technion, Haifa 32000, Israel; 
phone 04-293273; telex 46406 TECON IL. 
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CAREER OPPORTUNITIES 


RATES: $10.00 per line, $100 minimum charge 
(up to ten lines). Average six typeset words per 
line, nine lines per column inch. Add $8 for box 
number. Send copy at least six weeks prior to 
month of publication to: Sandra J. Arteaga, 
Classified Advertising, COMPUTER Magazine, 
10662 Los Vaqueros Circle, Los Alamitos, CA 
90720. 

To allow sufficient time for distribution of the 
magazine, schedule your job application dead¬ 
lines at least four weeks after issue date (e.g., 
deadline of Nov. 28 to send applications re¬ 
sponding to ad appearing in Nov. issue). 

Note: IEEE Computer Society member ads for 
positions wanted $10 up to 10 lines, $1 per line 
thereafter. Situations wanted ads run free for 
unemployed society members. Include IEEE 
member number in either case. 

In order to conform to the Age Discrimination in 
Employment Act and to discourage age discrim¬ 
ination, COMPUTER may reject any advertise¬ 
ment containing any of these phrases or similar 
ones: “.. .recent college grads..“.. .1-4 
years maximum experience..up to 5 
years experience...," or “...10 years max¬ 
imum experience." COMPUTER reserves the 
right to append to any advertisement, without 
specific notice to the advertiser, “Experience 
ranges are suggested minimum requirements, 
not maximums.” COMPUTER assumes that, 
since advertisers have been notified of this 
policy in advance, they agree that any ex¬ 
perience requirements, whether stated as 
ranges or otherwise, will be construed by the 
reader as minimum requirements only. 


SUPERCOMPUTING CENTER MANAGER 

The University of Texas System Center for High 
Performance Computing (CHPC) is seeking qual¬ 
ified applicants for the position of Manager. The 
UT System CHPC is equipped with a Cray 
X-MP/24 supercomputer with SSD, two front-end 
computers, NSC hyperchannel, image graphics 
and other facilities. Located in Austin, the UT 
System CHPC serves 13 component institutions 
of The University of Texas System through a 
dedicated computer network. The UT System 
CHPC reports to the Office of the Chancellor, 
The University of Texas System. 

Manager will be responsible for directing all 
aspects of the UT System CHPC, including the 
coordination of research programs in high per¬ 
formance computing conducted by UT System 
faculty under a UT System CHPC administered 
grant program. 

Applicants should have the following qualifi¬ 
cations: five or more years experience in suc¬ 
cessfully managing a substantial research 
computing facility, be knowledgeable in high 
performance computing and telecommunication 
technologies, and possess a respectable re¬ 
search and publication record. An earned doc¬ 
toral degree is preferred. Salary is commen¬ 
surate with qualification and experience. 
Applications with complete resumes should be 
directed by July 1,1986 to The University of Tex¬ 
as System Center for High Performance Com¬ 
puting, P.O. Drawer S, Austin, TX 78713-7388. 
The University of Texas System is an Equal 
Opportunity-Affirmative Action Employer. 


POSITION NOTICE 
COMPUTER SCIENTIST 

An immediate opening is available for a Com¬ 
puter Scientist in supercomputing research and 
development. This is a university position. The 
primary responsibility of the position will be to 
participate in the design and development of 
numerical and non-numerical algorithms for 
multiprocessors. Specific applications include 
the analysis and implementation of weather 
modeling packages (finite differences as well as 
spectrum methods). The successful applicant 
must be able to interact with hardware profes¬ 
sionals (for the design of interconnection net¬ 
works and global memory) and with software 
developers (for the design and implementation 
of multiprocessor compilers and operating sys¬ 
tems). Duties also include the installation and 
maintenance of mathematical libraries and ap¬ 
plication models, and the provision of assis¬ 
tance to faculty members in the use of the sys- 

Minimum qualifications include: A Master’s 
degree in Computer Science, advanced course- 
work or experience in numerical weather predic¬ 
tion and numerical methods in fluid dynamics; 2 
years experience as a computer program¬ 
mer/programmer analyst working with FOR¬ 
TRAN and scientific programming and exposure 
to a variety of engineering and scientific 
packages and libraries. Also required is ex¬ 
perience with VAX UNIX computers, which may 
be obtained during graduate studies. 

Salary will be between $33,000 and $40,000 
depending upon qualifications and experience. 
Send resumes, including names of at least three 
references to: 

Mrs. Wanda Byrd 

Illinois Job Service 

402 North Randolph 

Champaign, IL 61820 

Reference No. 020062 

This is an Employer Paid Ad AA/EOE 


POSITIONS FOR LECTURER (non tenure-track) 
or assistant professor ($23,976-28,884.), lecturer 
or associate professor ($29,100-35,064.) or lec¬ 
turer or full professor ($36,744-44,352). Available 
in January, April or Sept., 1986. Offer undergrad 
courses, advise students, participate in cur¬ 
riculum development and program evaluation, 
participate in other courses as appropriate to in¬ 
dividual’s education and experience. Teaching 
load an equated twelve hours per week of lecture 
and lab. The Ph.D. in CSci is preferred; Master’s 
in CSci with doctorate in related field or equiva¬ 
lent experience will be considered. Facilities 
currently consist of CDC Cyber 720 and 730-760, 
PDP 11/45 and PDP 11/24 computers, many IBM 
PCs, Apple lie’s, Macintoshes, microprocessors 
and terminals. A Prime 9750 Super-mini comput¬ 
er is expected. Candidates should submit letter 
of application, resume, three letters of recom¬ 
mendation and all official transcripts. Applica¬ 
tions will be accepted until the positions are 
filled. Send all materials to: 

Dr. James D. Crum, Dean 
School of Natural Sciences 
California State University 
5500 University Parkway 
San Bernardino, CA 92407 
An equal opportunity/affirmative action, Section 
504, Title IX employer. 


RESEARCH-ARTIFICIAL INTELLIGENCE 

Large research lab in the Baltimore, MD area in¬ 
vites applications for the position of Scientist in 
Research-Artificial Intelligence. Successful ap¬ 
plicant will be principal investigator for natural 
language processing and will perform research 
in knowledge representation and text under¬ 
standing. Functions include building a logic 
knowledge base, developing the requirements 
and system specs for a text generation system 
to convert logic representations in the base into 
English discourse (more than one sentence) for 
an Inference Machine Laboratory. Ph.D. in 
Linguistics with emphasis on Computational 
Linguistics required. Must be proficient with 
VAX, LISP, Symbolics and Prolog and have good 
research and communication skills. Minimum of 
one year of experience required. Free benefit 
package. Will relocate. Salary $39,390-42,500. 
AA/EOE/M/F. Send resumes to Dept, of Employ¬ 
ment & Training, 1123 N. Eutaw St., Baltimore, 
MD 21201. Refer to Job Order #5054806. 


UNIVERSITY OF WISCONSIN-MADISON 
FACULTY POSITIONS 

The Department of Electrical and Computer 
Engineering invites applications for tenure and 
tenure-track faculty positions. A Ph.D. degree is 
required, and successful candidates are ex¬ 
pected to participate in both teaching and 
research activities. Applicants in all areas of 
computer engineering are invited to apply, but 
the following areas are of special interest: com¬ 
puter architecture, computer networks, real-time 
computer applications, design automation, VLSI 
circuit design, and engineering applications of 
artificial intelligence. Rank and salary will be 
commensurate with qualifications and experi¬ 
ence. Send resume and names of three refer¬ 
ences to F.G. Stremler, Chairman, Department of 
Electrical and Computer Engineering, University 
of Wisconsin-Madison, 1415 Johnson Drive, 
Madison, Wl 53706, an equal opportunity/affir¬ 
mative action employer. 


CLEMSON UNIVERSITY 
COLLEGE OF ENGINEERING 

The College of Engineering at Clemson Universi¬ 
ty is accepting applications for the position of 
Coordinator for Computer Services. Responsibil¬ 
ities will include: teaching fundamental courses 
in computer programming/applications, assist¬ 
ing in the specification/acquisition of hardware 
and software, and providing support to the facul¬ 
ty and students in the application of the com¬ 
puter to the instructional and research pro¬ 
grams. Qualifications: M.S. or Ph.D. degree with 
at least one degree in engineering, 3-5 years ex¬ 
perience in a comparable position at a university 
or an industry, and demonstrated managerial ex¬ 
perience. Salary commensurate with experience 
and qualifications. Send resume and supporting 
materials to: 

Dr. Walter E. Castro 

Assistant Dean for Undergraduate Studies 
113 Riggs Hall 
Clemson University 
Clemson, SC 29634-0901 
Applications will be accepted until the position 
is filled. 

Clemson University is an affirmative action, 
equal opportunity employer. 
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UNIVERSITY OF MARYLAND 
DIRECTOR 
INSTITUTE FOR 

ADVANCED COMPUTER STUDIES 

The University of Maryland Institute for Ad¬ 
vanced Computer Studies (UMIACS) was estab¬ 
lished in January 1985 by Maryland Governor 
Harry Hughes. UMIACS resides on the University 
of Maryland College Park Campus with ready ac¬ 
cess to the vast scientific, industrial, and govern¬ 
mental communities in the metropolitan Wash¬ 
ington D.C. area. UMIACS is intended to serve 
the entire University of Maryland system as a 
center for research activities in computing. Cur¬ 
rent fields of interest include parallel computa¬ 
tion, artificial intelligence, software engineering, 
and computer systems. 

A permanent Director is now being sought for 
UMIACS. The Director will have an unusual op¬ 
portunity to guide the formation, development, 
and operation of this new Institute, and should 
be a person with exceptional research and ad¬ 
ministrative abilities. 

UMIACS currently has 11 tenure-track or tenured 
faculty lines, and a substantial operating budget 
for faculty research support. Within three years, 
UMIACS will grow to thirty research faculty 
lines. These lines will be used for joint tenure- 
track appointments with other University depart¬ 
ments as well as for permanent full-time senior 
appointments in the Institute with tenure to 
reside in an academic department. 

Applicants for the UMIACS Directorship should 
send a complete, certified, curriculum vita, and 
names of four references to: Dr. Alex J. Dragt, 
Division of Mathematical and Physical Sciences 
and Engineering, University of Maryland, College 
Park, MD 20742. For full consideration, applica¬ 
tions should be received by June 1,1986. 

The University of Maryland is an equal oppor¬ 
tunity, and affirmative action employer. 


THE UNIVERSITY OF RHODE ISLAND 

Assistant Professor, Computer Engineering. 
Tenure track faculty position. Applicants must 
hold a Ph.D. in Electrical or Computer Engineer¬ 
ing or Computer Science with one or more areas 
of specialization such as LSI/VLSI design, com¬ 
puter architecture, artificial intelligence,’ com¬ 
putational complexity, real-time computing, 
fault-tolerant computing, parallel processing or 
computer networks. Department has well- 
equipped laboratories for research in computer 
architecture, VLSI design, computer vision, and 
signal-and-image-processing. Computing is sup¬ 
ported by a DATA GENERAL MV 10000, VAX 
11/780, Eclipse S250, LSI-11 and a microcom¬ 
puter laboratory, and on campus by an IBM 4381 
mainframe and two PRIME 9955 minicomputers. 
Send a letter of application, resume and 3 
references by July 1, 1986 to: Professor G. 
Lengyel, Search Committee Chair, Assistant 
Professor, Electrical Engineering (080116) Posi¬ 
tion, THE UNIVERSITY OF RHODE ISLAND, P.0 
Box 357, Kingston, Rl 02881-0357. An affirmative 
action/equal opportunity employer m/f. 

BARRETT LABORATORIES 

SYSTEMS ANALYST: Analyze, create, design, 
code and document software applications for 
clinical laboratory testing, data flow, including 
hematology, coagulation, blood gas and urinaly¬ 
sis lab testing procedures. Knowledge or train¬ 
ing in modelling, computer structure and soft¬ 
ware design, software development, DBMS pro¬ 
gramming and “C” language. BS or equivalent in 
Computer Science/Math. $2,082/mo. Job Site- 
Rancho Cordova, CA. Clip this ad and send with 
resume to Job #MA 1365, P.O. Box 9560, Sacra¬ 
mento, CA 95823-0560 not later than 30 days 
from the date of this publication. 


Computer Engineering 
The Pennsylvania State University 

Applications are invited for tenure-track and 
visiting faculty positions at all levels. Candi¬ 
dates from all areas of computer engineering 
(hardware and software) will be considered. 
Computer Engineering at The Pennsylvania 
State University is within the Department of 
Electrical Engineering which has about 40 facul¬ 
ty members, and approximately 1800 undergrad¬ 
uate majors, 120 graduate students. Candidates 
should have a Ph.D. in Electrical/Computer Engi¬ 
neering or related areas. Excellent instruction 
and research computing facilities are available 
within the Department, College and at the Uni¬ 
versity Computing Center. 

Please send your letter of application, resume, or 
inquiries, together with three references to: T. 
Feng, Computer Engineering Program, Depart¬ 
ment of Electrical Engineering, 129 Electrical 
Engineering East, Box Z, The Pennsylvania State 
University, University Park, PA 16802. 

Deadline for Application is May 31,1986, or until 
suitable qualified candidates are selected. “An 
Equal Opportunity/Affirmative Action Employer.” 

PROFESSORS OF COMPUTER ENGINEERING 
UNIVERSITY OF MIAMI 

Department of Electrical and Computer Engi¬ 
neering has a SENIOR FACULTY position with 
added responsibility for directing the Computer 
Engineering Program. A JUNIOR FACULTY posi¬ 
tion is, also, available. Senior applicants are ex¬ 
pected to have proven records of research, in¬ 
cluding funded research, and experience in 
Ph.D. programs. Junior applicants should have 
demonstrated potential for excellence in 
research and teaching as well as doctoral degree 
in a computer related area. Rank and salary com¬ 
mensurate with qualifications and academic or 
industrial experience. The department has 
VAX-11/750, two MICRO VAX II, several AT&T 
3B2’s and other microcomputers as well as ac¬ 
cess to IBM & UNIVAC Systems. Please forward 
resume to: Chairman, Electrical & Computer 
Engineering Department, University of Miami 
P.O. Box 248294, Coral Gables, Florida 33124. An 
Affirmative Action Equal Opportunity Employer. 

FACULTY POSITIONS 
COMPUTER SCIENCE AND ENGINEERING 
DEPARTMENT 
AUBURN UNIVERSITY 
AUBURN, ALABAMA 

Applications are invited for tenure-track faculty 
positions as Assistant/Associate/Full Professor. 

A Ph.D. in Computer Science, Computer Engi¬ 
neering, Electrical Engineering or a closely 
related discipline is required. Areas of interest 
include Software Engineering, Distributed Com¬ 
puting, Computer Architecture, Artificial In¬ 
telligence, Knowledge Based Systems, System 
Software, Progamming Languages and Data 
Base Systems. Several positions are open for the 
86/87 academic year. Salary and faculty rank are 
dependent upon experience and qualifications. 
Responsibilities include teaching at the grad¬ 
uate and undergraduate levels and research. The 
department offers Bachelor’s degrees in Com¬ 
puter Science and Computer Engineering as well 
as the M.S. and Ph.D. An outstanding research 
program has been established in most of the 
above disciplines. 

Applicants should submit a detailed resume and 
the names of three references to: 

Charles R. Vick 
Department Head 

Computer Science and Engineering 
Auburn University, AL 36849 
Auburn University is an Equal Opportunity/Affir¬ 
mative Action Employer. 


FACULTY POSITIONS 
SCHOOL OF ENGINEERING 
Department of Industrial Engineering and 
Computer Science 

Applications are invited for two computer 
science faculty positions in a growing depart¬ 
ment. These are tenure-track posts for those hav¬ 
ing a Ph.D. in Computer Science or in a related 
field. However, candidates pursuing a doctoral 
program or having other substantial computer 
science qualifications are encouraged to apply 
and may be considered for non-tenure-track 
posts. The successful applicant should have 
broad competence and special expertise in at 
least one of the major areas of computer 
science, such as the following: operating sys¬ 
tems, structure and translation of programming 
languages, information systems, computer ar¬ 
chitecture and communications, mathematics 
of computing, numerical analysis, data struc¬ 
tures, database systems, computer applications 
to manufacturing processes, computer graph¬ 
ics, artificial intelligence. Responsibilities in¬ 
clude teaching at the undergraduate and 
graduate levels and development of curricula 
and research programs. Appointments com¬ 
mence September 1, 1986. Salary will be based 
on qualifications and experience. Applications 
should be submitted by May 15, 1986 to: 

Dr. Roger G. Frey 

Department of Industrial Engineering 
and Computer Science 
University of New Haven 
West Haven, Connecticut 06516 
The University of New Haven is an equal oppor¬ 
tunity affirmative action employer. Women and 
minorities are encouraged to apply. It is located 
in a desirable area, easily accessible to the cul¬ 
tural and educational attractions of New York 
and Boston, and of course New Haven, as well as 
the recreational attractions of Southern New 
England. 


NASA/AMES RESEARCH CENTER 

NASA Ames Research Center, located about 25 
miles south of San Francisco, CA, is emerging 
as a leading organization in artificial intelligence 
research and engineering with current programs 
in aeronautics and space with special emphasis 
on Space Station applications. In the space pro¬ 
gram, Ames has the lead role for NASA's Al 
research efforts and for the NASA/OAST-spon- 
sored Ground-based Systems Autonomy Dem¬ 
onstration Program. We are seeking highly 
qualified researchers trained in Al techniques to 
join our staff in work involving technical manage¬ 
ment oversight, transfer of basic Al technology 
to aeronautics and space applications, and con¬ 
ducting specific research in the following major 
areas: 

• EXPERT SYSTEMS 

• PLANNING SYSTEMS 

• KNOWLEDGE UNDERSTANDING AND 
REPRESENTATION 

• REASONING UNDER UNCERTAINTIES 

• MACHINE LEARNING 

• SYMBOLIC ARCHITECTURES 
Applicants should have demonstrated experi¬ 
ence in any of the above areas with the ability to 
program in LISP on LISP machines (Symbolics 
3600, 3670, 3640; Tl Explorer; Micro-VAX II) and 
technical leadership to head up major Al pro¬ 
grams. Positions are open at the Ph.D. level and 
Master's level. 

U.S. citizenship required. Equal Opportunity 
Employer. Please send a detailed resume/SF 171 
and salary history to: 

Yuriko Sarjeant 
Personnel Manager 
Mail Stop 241-6 (RI-2) 

NASA Ames Research Center 
Moffett Field, CA 94035 
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SENIOR SOFTWARE ENGINEER 


OREGON STATE UNIVERSITY 


Design, implement and port communication pro¬ 
tocol architectures such as CCITT X25, X28, X29 
Xerox network systems architecture and open 
systems architecture to M68000 processor 
based hardware configurations for UNIX* oper¬ 
ating system environment, etc. M.S. or equiva¬ 
lent in Electrical Communication Engineering or 
Computer Science. 1-2 years experience in 
computer network engineering. Experience in 
software development for design and implemen¬ 
tation of communication protocols including 
CCITT X25, X28 and X29 for computer network¬ 
ing in UNIX O.S. for M68000 microprocessor- 
based architecture. Also experience with ether- 
net (LAN) system architecture and open system 
interconnection architecture, and working 
knowledge of C and Assembly languages. $3400/ 
mo.; 40 hrs/wk. Job site in San Jose, CA. Must 
have legal right to work. Clip ad and send with 
resume to: Job Order Number MLU #0246, P.O. 
Box 9560, Sacramento, CA 95823-0560. 'UNIX is 
a registered trademark of AT&T Bell Laborator¬ 
ies. Applicants must respond by May 22,1986. 

THE UNIVERSITY OF ALBERTA 
DEPARTMENT OF COMPUTING SCIENCE 

The Department of Computing Science is 
-undergoing an extensive expansion in research 
initiatives. Applications are invited for four 
tenure-track positions at the Assistant/Asso¬ 
ciate Professor level. Responsibilities include 
research as well as teaching at the graduate and 
undergraduate levels. Candidates from all areas 
will be considered. Current hardware support in¬ 
cludes an Amdahl 5860, a network of VAX 
11/780’s, and well equipped mini and micro com¬ 
puter laboratories for graphics, VLSI and Al 
research. Access to a Cyber 205 is available. 
Salary range is $30,316 to $48,970 and is com¬ 
mensurate with qualifications and experience. 
Send curriculum vitae, names of three refer¬ 
ences, and up to three reprints or papers. New 
Ph.D’s should also include a copy of their trans¬ 
cript. Apply to: Dr. Lee White, Chairman, Depart¬ 
ment of Computing Science, University of Alber¬ 
ta, Edmonton, Alberta, T6G 2H1. Applications 
will be accepted until May 31,1986. The Univer¬ 
sity of Alberta is an equal opportunity employer. 


CARLETON UNIVERSITY 
ELECTRICAL ENGINEERING 
COMPUTER ENGINEERING 

Applicants are invited for tenure track, term or 
visiting appointments at the lecturer and 
assistant/associate professor levels. 

Duties will include teaching and research at the 
undergraduate and graduate levels in areas such 
as microcomputer applications in automatic 
control or communications, real-time program¬ 
ming, microprocessor hardware and architec¬ 
ture, and computer design. A strong hardware/ 
software background is required. 

The department’s computing facilities include, 
in addition to the University's mainframe, an 
Ethernet-based LAN consisting of a VAX 11/750, 
SUN 68000s, many PDP 11s, 8086s, and an Intel 
development system network. 

Applicants should have a Ph.D. degree or equiva¬ 
lent in electrical engineering or a related disci¬ 
pline. Registration as a professional engineer 
would be an advantage. In accordance with Ca¬ 
nadian immigration requirements, this adver¬ 
tisement is directed to Canadian citizens and 
permanent residents, however, others may be 
eligible. The positions are open to both men and 
women and are subject to budgetary approval. 
Send a curriculum vitae and names of references 
to: Dr. B.A. Bowen, Chairman, Department of 
Systems and Computer Engineering, Carleton 
University, Ottawa, Canada K1S 5B6. 


DAHLGREN CHAIR 
COMPUTER SCIENCE 
VIRGINIA TECH 

Applications and nominations of distinguished 
computer scientists are sought for the John 
Adolphus Dahlgren Chair, created in the Depart¬ 
ment of Computer Science at Virginia Tech 
through a research agreement with the U.S. 
Navy. The Chair provides unique opportunities 
for large-scale research projects through the 
university’s multidisciplinary Systems Research 
Center. 

Candidates with distinguished records in re¬ 
search and scholarship are sought who can exer¬ 
cise a leadership role among the 20 computer 
science faculty and also provide guidance to 
research programs pursued by Naval labora¬ 
tories. Candidates are particularly sought who 
have expertise in software engineering, artificial 
intelligence, distributed processing systems, 
human/computer interaction, and/or perfor¬ 
mance analysis. 

To submit applications or nominations, or for ad¬ 
ditional information, contact Dr. Dennis Kafura, 
Dahlgren Chair Search Committee, Department 
of Computer Science, Virginia Tech, Blacksburg, 
VA 24061 by mail; (703) 961-6931 by phone; or 
“kafura@vpi” by CSNET. The search will con¬ 
tinue until the position is filled. 

Virginia Tech is an equal opportunity/affirmative 
action employer. 


TEMPLE UNIVERSITY 
FACULTY POSITIONS 


The Department of Computer and Information 
Sciences has tenure-track and adjunct faculty 
positions available for exceptional people at the 
Associate and Assistant Professor levels, in all 
areas of computer science. 

Applicants should hold the Ph.D. degree in Com¬ 
puter Science, Information Systems, or a closely 
related field. Ability to contribute to strong in¬ 
structional and research programs, both under¬ 
graduate and graduate, will be the primary re¬ 
quisite for appointment. Salary and rank will be 
determined by the appointee’s experience. An 
applicant for a senior position should have a 
strong record of scholarly achievement, while an 
applicant for an assistant professorship should 
present evidence of research potential. 

The Computer Science Department offers pro¬ 
grams leading to the Bachelors, Masters and 
Ph.D. degrees in Computer Science and in 
Business Administration/Information Science. 

A networked departmental computing facility in¬ 
cludes a VAX-11/780, VAX-11/750,10 microVAX II 
workstations, and 10 microVAX I workstations. 
The facility also includes an AT&T 3B2, Tl Ex¬ 
plorer, an image processing laboratory, several 
PDP-11 based timesharing systems, and an in¬ 
structional laboratory consisting of a large 
number of PDP-11 and LSI-11 computer systems. 
Available University facilities include a CDC 750, 
an IBM 3081, an IBM 4381 and several microcom¬ 
puter laboratories. 

Temple University is an Equal Opportunity/Affir¬ 
mative Action Employer. Minorities and women 
are encouraged to apply. 

To apply, submit vitae, and bibliography to: 
Eugene Kwatny 

Chairman of Faculty Search Committee 
Department of Computer and Information 
Sciences 
Temple University 

Computer Activities Building, 038-24 
Philadelphia, PA 19122 
(215) 787-8450 


The Department of Computer Science invites 
qualified applicants for assistant, associate and 
full professors, tenure-track and visiting. Spe¬ 
cialization in programming languages, operating 
systems, artificial intelligence, information 
based systems, theoretical computer science, 
computer systems organization, or computer 
graphics is desirable. Applicants should have 
completed or expect to complete all require¬ 
ments for a Ph.D. in computer science or a close¬ 
ly related field, and should have demonstrated 
research and teaching potential. Candidates for 
senior positions should have an established re¬ 
search reputation. Please send resume, includ¬ 
ing the names of three references, to: Walter G. 
Rudd, Chairman, Department of Computer Sci¬ 
ence, Oregon State University, Corvallis, OR 
97331. 

Oregon State University is an Equal Opportunity/ 
Affirmative Action employer and complies with 
Section 504 of the Rehabilitation Act of 1973. 

PROFESSIONAL SERVICES 
CONSULTANT ANALYST 

Conducts logical analyses of business pro¬ 
cedures and problems using the advanced 
techniques of structured analysis and for¬ 
mulates structured designs of alternative solu¬ 
tions by computer. Specifies detail logical and 
mathematical operations to be performed by 
equipment units and computer programs. Tests 
system adequacy and prepares system docu¬ 
mentation for implementation. Must have 
Bachelor of Science or Arts degree and 4 years 
of related experience in systems analysis and 
design with direct involvement in the develop¬ 
ment of at least 3 application areas or systems. 
Must have knowledge of techniques of struc¬ 
tured analysis. Salary to $36 K p.a. Job site Los 
Angeles. Send this ad and resume to Job 
#AT-5777, P.O. Box 9560, Sacramento, CA 
95823-0560 not later than May 31, 1986. 
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1986 SUMMER USENIX CONFERENCE 
[ AND VENDOR EXHIBITION J 

Atlanta Hilton Hotel — Atlanta, Georgia 
JUNE 9 - 13, 1986 


The Professional and Technical UNIX* Association 

TECHNICAL SESSIONS 

Exploring issues of interest to the UNIX technical community, these sessions 


prouide a forum for presentation and discussion on a variety of topics. 
Suggestions for formal papers, panel discussions and informal discussions will 
include the following: 

• Operating Systems Design 

• Remote Filesystems 

• The Philosophy and 
Theology of UNIX 


The Audio-Visual UNIX 

• Computer Typography 

• User Interface Technology 

• Electronic Mail Systems 


TUTORIALS 

Presented by leading UNIX experts, the tutorials provide in-depth coverage of 
essential issues in UNIX technology. Topics include: 


* System Administration 
► Managing Networks and others 


• 4.X and System V Internals 

• Networking 

• Device Drivers 

VENDOR EXHIBITION 

Vendors are invited to display advanced technology and applications relevant 
to the UNIX technical community. 

THE SPONSOR 

For the latest in UNIX applications and research, people look to USENIX, a 
non-profit association of individuals and institutions dedicated to fostering 
the development and communication of UNIX and UNIX-like systems and the 
C programming language. USENIX sponsors technical conferences, publishes 
;login:, USENIXs newsletter and serves as coordinator of a software exchange 
for appropriately licensed members. 

For complete conference information, call: 

(213) 592-1381 or (213) 592-3243 

Or write: USENIX Conference Office, P.O.Box 385, Sunset Beach, CA 90742 

• UNIX is a trademark of AT&T Bell Laboratories 



















































PEOPLE WHOSE 
COMPUTER GRAPHICS 
CHALLENGE REALITY 
SHOULD BE HUNG. 


When we announced our computer graphics image 
contest, we had certain people in mind. People who com¬ 
bine technical skill with the desire to push frontiers a little 
farther. People who believe that computer graphics can 
bridge the physical world and the human imagination. 

We received hundreds of entries. Nine now hang in 
Bostons Computer Museum. And though not everyone 
could win, we think each image is a testament to the power 
of computer graphics as a creative tool. 

At Raster Technologies, we make a full range of high 
performance, intelligent color graphics systems designed for 
easy application development. 


Our Model One/380 3-D display system can locally 
create images of unparalleled realism, to let you work more 
efficiently and productively in applications like simulation, 
research, mechanical CAE, and geophysical analysis. 

To see how far you can take a project when your tools 
are equal to the challenge, give us a call. 

The benchmark of computer graphics, .fcfcl 

Raster Technologies, Incorporated 

Two Robbins RoadAVestford, Massachusetts 01886 

Tel (617)692 7900 1-8004RASTLR (outside MA) 

TWX 710 347 0202 


Image Credits (I r): Wilson Burrows, Marcia McDevitl, Cranston/Csuri Productions, Inc., Andrew PeareefMilart 
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